Hogy ez a változat hogyan alakult ki, irreleváns.
Abszolút nem értek veled egyet; a PR végterméke, végeredménye nem egy lenyomat (nem a fa állapota az utolsó commitnál), hanem a commit history-nak egy szakasza (esetleg részgráfja). A kódot (és a kommenteket és a commit message-eket) elsősorban emberek közötti kommunikációra írjuk; az mellékes, hogy a gép futtatni is tudja. (Sarkítok, de érted, mire gondolok.) A PR végterméke az, hogy az egész gondolatmenet, aprólékosan, fokozatosan felépítve, megmarad a commit history-ban. Ha van egy hiba a kódban, amely egy olyan téves elgondolásból származik, amely a patch set közepét érinti, akkor a javítás nem az, hogy a végére rádobjuk a fixet (azért, hogy te könnyen megnézhesd azt az 1 dolgot), hanem az, hogy a patch set közepén kijavítjuk a hibás patch-et, frissítjük hozzá a commit message-et (amelyben a téves elgondolás szerepel), kiegészítjük az adott patch changelog-ját. Ezután a reviewer megnézi az egész új patch set verziót inkrementálisan (git-range-diff-fel). Nemcsak azt fogja látni, hogy a végső kód, a végeredmény (ami futni fog) jó, hanem azt is látni fogja, hogy a patch set közepén, az eredeti helyén, a gondolati hibát kijavítottuk. Az adott patch előző és mostani változatát összehasonlítva (ami egy interdiff) a reviewer látni fogja a commit message, esetleg a commit subject (!) változását is -- a github képtelen commit message-eket összehasonlítani, ami pedig nagyon nagy hiba; szerk.: hasonlóan, nem enged a commit message-hez kommenteket fűzni --, és persze azt is, hogy a patchen belüli változás hogyan változott meg. Ha úgy tetszik: második deriváltat néz.