Mám pocit, že PR na Githubu by měly být nahrazeny nástroji na straně klienta. PR -> nějaký signál, který požaduje sloučení větve do cílové větve PR review -> znovu použít stejný signál jako výše, odeslat PR na vrcholu PR větve Nyní diff hunky potřebují komentáře řízené revizí. Hotový.

/připomenout si, že jsem se podíval na nové vydání @radicle_xyz, které se zaměřuje na lokální decentralizovanou správu revizí včetně ticketingu a spolupráce s pobočkami...

Upřesnění: "diff hunk comment" má za cíl naplnit funkčnost komentáře k recenzi GH: Je sledován v historii revizí, anotuje kus (např. "toto API fn musí být asynchronní", kde následující části převádí funkci) a nezobrazuje se v kódu.

Vůbec by mě nepřekvapilo, kdyby git už toto sestavení někde (pod vrstvami složitosti) měl, protože je velmi blízké stylu "e-mailové záplaty spolupracovníkům", který je bližší kořenům gitu. Zvratem je kontrola revizí diff *comments*.

Vysvětlení 2: Původní předkladatel může reagovat na "recenzi PR" buď přijetím rozdílu, nebo vytvořením třetí žádosti o přijetí změn nad recenzním návrhem (odpověď na recenzi). Tento ping-ponging pokračuje, dokud obě strany nepřijmou všechny úpravy. Interakce se ukládá do historie

ps: Hackuji decentralizovaný lokální nástroj pro správu první revize jako koníček (~rok do ∞ datum odeslání). Chtěl bych, aby podporoval tyto případy použití: - Proces PR podle výše uvedeného - rozlišení může způsobit "zmáčknutou" jedinou změnu jako součást "příběhu" - Celá historie je stále k dispozici