In <[🔎] 87ocayo1en.fsf@anar.kanru.info>, Kan-Ru Chen wrote: >Goswin von Brederlow <goswin-v-b@web.de> writes: >> Paul Wise <pabs@debian.org> writes: >>> I would also suggest that before you push, either judicious use of git >>> add -p for preparing commits into logical changes or use of git rebase >>> -i after the fact to reorganise them into logical changes. Also, >>> ensuring that each commit builds and passes any test suite helps folks >>> doing bisects etc on the repo at a later date. >> >> I'm always unsure on how this is supposed to work. On the one hand you >> split up changes into many commits. On the other hand each commit should >> be functional so bisect works. Somehow the two ideas conflict in my >> head. > >No, you split up changes but keep it functional. If splitting a chunk >breaks the functionality, then it means they are relevant and should be >committed at once. "as one" not "at once". "as one" ~= together "at once" ~= with little or no delay The goal is to have commits be as big as they need to be, but no bigger. If there is no "proper subset" of your commit that you can apply and have a "working" build, then your commit is just the right size to stand alone. E.g. If you add a new function, and fix up a few places to use the new function instead of copy-pasta, that should be two or more commits. E.g. If you change the API of a existing function, and fix up all the callers, that should be one commit. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.