Re: How to commit incomplete changes?

From: Neal Kreitzinger <nkreitzinger@gmail.com>
Date: Dec 15, 2011, 22:51 UTC
Message-ID: <4EEA79E0.4070700@gmail.com>
In-Reply-To: <4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no>

On 12/14/2011 5:24 PM, Hallvard B Furuseth wrote:

Show 12 quoted lines

> 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