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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html