Ty patche co jsou strojove - a vicemene formatovaci, pro dodrzeni konvenci, by meli byt aplikovany pred vydanim naraz. Nebo udelat cleanup minor verzi, kdy se uklidi ruznej bordel.
A pak to muze mit format - co patch, to jedno formatovaci pravidlo. A ne ze se to bude posilat po drobkach..
Jinak formatovaci patche jsou jedna ze slabin GITu - kdyz vam tam ujede treba tab, nebo mezery na konci radku a snazite se to napravit.. tak to zasvini hezkou historii i git blame.. holt nekdy by bylo potreba zasahnout i do starsich commitu a nechat je updatnout (verzovat, revizovat - dalsim clovekem).
Tak pro prijeti do kernelu by mel commit uspesne projit pres checkpatch.pl, rada maintaineru to (automaticky) kontroluje. Ten formatovaci chyby odchyti (bohuzel ne treba u DTS a obecne non-C kodu).
Zpetne commit opravit muzes pres rebase, ale samozrejme nesmi byt jeste sdilen, aby v tom ostatni nemeli gulas. Jak bys to chtel delat, kdyz kazda zmena vygeneruje novy hash commitu?
Jsem tak nejak mel za to ze kazdy pricetny programator, co se hodla pochlubit svym dilem, pouziva nejaky lint co mezery na konci radku a taby navic srovna.
Git nemuze vedet jestli zrovna pracuje s jazykem kde mezera na zacatku je extremne dulezita (python) nebo naprosto nedulezita (latex).
A kdyz vyvojar udela blby commit, a pak si jeste opravi format dalsim commitem, tak jsem mel za to ze na to tu je nastroj squash, ne?