Re: How to commit incomplete changes?

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 12/14/2011 5:24 PM, Hallvard B Furuseth wrote:
> Do people have any feelings or conventions for how and when to publish
> a series of commits where the first one(s) break something and the next
> ones clear it up? I've found some discussion, but with vague results.
>
> I'm about to commit some small edits which go together with bigger
> generated changes. It seems both more readable and more cherry-pick-
> friendly to me to keep these in separate commits.
>
> What I've found is I can use a line in the commit message like
> "Incomplete change, requires next commit (update foo/ dir)."
> and, if there is any point, do a no-ff merge past the breakage.
>
A main purpose for the squash and fixup options is (as Randall Schwartz 
put it in his git video http://www.youtube.com/watch?v=8dhZ9BXQgc4) "To 
make it look like you did it all perfectly without making any mistakes" 
(or a reasonable facsimile thereof).  You insights on the cherry-picking 
of fixes is interesting, but makes no sense in the context of 
unpublished work.  Why would you need to cherry-pick fixes to mistakes 
that have not yet been propagated (published)?  If the cherry-picks of 
fixes are for your other already merged local branches then just save 
the pre-squash/fixup version of the branch to another branch, (ie, git 
branch mybranch-b4-fixup) and cherry-pick from that unsquashed copy to 
patch up your other unpublished branches.  Keep in mind that cherry-pick 
is not alway the best way to apply fixes.  A merge or rebase to get the 
fix is the sign of a better workflow in many cases, TBOMK. On the other 
hand, if the bugs have been published then you have no choice but to 
commit the fix separately because you can't rearrage/edit published 
history.  Keep in mind that ideally commits should be logical.  You can 
use the rearrage feature of interactive rebase to squash fixes into the 
feature commit they go to. IOW, I don't think squashing everything into 
a giant commit just to consolidate bugfixes into a single commit makes 
sense if that would mean losing the distinct separation between 
differing feature commits.

I assume by 'generated changes' you mean the automerge in git that is a 
wonderful default for vast systems like the linux kernel in which code 
is unlikely to overlap logically, but very dangerous in legacy 
application systems where changes to the same file can create logical 
bugs despite not being on the 'exact same line of code'.  You are 
supposed to review all your merged files after a merge regardless. 
However, we don't trust ourselves that much in our shop so we force 
conflicts on same-file edits by making "user-date stamp" updates on 
"line 1" (depends on language-dependent comment line rules) in our 
pre-commit hook.  That way we are forced to manually review the merge of 
same-file edits "by hand" thus avoiding "generated results".  Of course, 
unique-file edits can still break things and thus a merge review is 
still in order.

Hope this helps.  I'm not a git workflow expert, but my comments are 
based on experience.  I too am still looking for better ways to manage 
workflow while leveraging the flexibity and agility of git for 
concurrent development.

v/r,
neal