Nem így van; a `git-notes` briliáns eszköz levlista-alapú fejlesztéshez. (Az más kérdés, hogy levlistákkal egyre ritkábban találkozni, de ettől még a use case létezik.)
Tipikusan akkor használjuk, amikor egy patch set-ből v1, v2, v3, ... vn változatot küldünk be, a bírálatokra reagálva. A beküldő a git-range-diff paranccsal összehasonlítja a legutóbbi (v(n-1)) és a legfrisebb (v(n)) verzióját a patch set-nek (development branch-nek), amely kijelzi mind a patch set szerkezeti változásait (patch-ek sorrendjének megváltoztatása, új patch-ek beszúrása, régi patch-ek kiesése), mind az egyes patch-eken belüli változásokat (interdiff formátumban, amit meg kell tanulni olvasni). A fejlesztő pedig ennek megfelelően patch-enkénti changelog-ot tart naprakészen, git-notes-szal. A git-rebase támogatja a git-notes-t, tehát új patch set version összeállításakor az egyes patch changelog-ját csak ki kell terjeszteni a tetején. A git-format-patch szintén támogatja a git-notes-t; a levlistán megjelenő patch email-eknek van egy dedikált szekciója, amelyben ez a changelog megjelenik. Rendkívüli mértékben támogatja az inkrementális review-t, úgyhogy az egyik legjobb eszköz.
A fenti interakcióban mind a bírálók, mind a beküldők jellemzően a patch set összes változatát megőrzik, külön branch-eken; a bíráló is a git-range-diff-et futtatja inkrementális review-hoz, lokálisan, és ehhez használja támogatásnak a levlistán olvasható, patch-enkénti "notes" szekciót. A git-am parancs (amellyel lementett email-ekből tudjuk az új verziójú branch-et felépíteni) szintén ismeri a "notes" szekciót, és átugorja.
Ezeket a patch-enkénti changelog-okat kifejezetten nem a commit message részeként akarjuk megtartani; amikor a végső változatot beolvasztjuk, akkor ez a changelog nem kerül a commit history-ba. A levlista archívumában megmarad, ha valakit érdekel (gyakran releváns tud lenni, igen).
A git-range-diff másik óriási előnye, hogy nagyon jól ellenáll ("reziliens") annak a helyzetnek, amikor egy rebase olyan master branch-ra történik, amelynek időközben elmászott a HEAD-je. Ilyenkor egy kumulatív git-diff szinte teljesen haszontalan, egy git-range-diff viszont zseniális.
A github-on és gitlab-on nevelkedett (vagy más szóval: satnyult) generációk ezt sajnos nem értik, nem is érthetik (nem az ő hibájuk), mert ezek a WebUI-k eleve nem támogatnak inkrementális review-t (tömören: olyan patch-enkénti összehasonlítását egy patch set két szomszédos verziójának, amelyet a git-range-diff végez). Így számukra értelmezhetetlen mind a patch-enkénti changelog, mind az interdiff formátum, mind (ennek folyományaként) a "notes" szekció, vagy maga a git-notes parancs.
A github egyik legnagyobb emberiség elleni bűntette a squash-on-merge bevezetése (mert arra neveli a fejlesztőket, hogy ne strukturálják a patch set-jeiket, miközben a patch set sorrendisége kritikus kommunikációs eszköz). A másik az inkrementális bírálat hiánya. A harmadik pedig az, hogy egy PR frissítéséhez ugyanazt a branch-et muszáj frissíteni (push vagy force-push), anélkül, hogy lenne automatizmus a branch korábbi változatainak megőrzésére, minimum addig, amíg a PR-t be nem olvasztják. Ez ugyanis azt jelenti, hogy aki pl. a harmadik vagy negyedik változatnál kapcsolódik be a review-ba, nem tudja áttekinteni a korábbi patch series változatok közötti strukturált változtatásokat, még akkor sem, ha hajlandó lenne a régi branch változatokat fetch-elni, és lokálisan git-range-diff-et futtani. Ugyanis nincs mit letölteni. Én már megtanultam, hogy minden branch változatot azonnal lehúzok lokálisba (amikor még friss -- akkor még le lehet), és ráragasztok egy verziózott lokális branch nevet. Így a patch set evolúciója legalább nálam megvan, amíg a review be nem fejeződik.
Egy szó mint száz, a github és tsai iszonyatos pusztítást végeztek a contribution/review workflow terén. Természetesen én sem tudom elkerülni a github-ot; bizton állíthatom, hogy olyan érzés a használata, a patch beküldős levlistákhoz képest, mintha a csukóim és a bokáim a hátam mögött gúzsba lennének kötve.
(Szerk. néhány typo/thinko javítása.)
End of rant.