At 2010-09-21 21:20:06 -0400, tgl@sss.pgh.pa.us wrote:
>
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches.
I'd suggest using "git cherry-pick -x" (or something similar) to mark
backported patches:
-x When recording the commit, append to the original commit message a note that indicates which commit this
changewas cherry-picked from. Append the note only for cherry picks without conflicts. Do not use this
optionif you are cherry-picking from your private branch because the information is useless to the
recipient.If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a
fixto a maintenance branch for an older release from a development branch), adding this information can be
useful.
I don't think it makes any sense to contort your workflow to commit to
different branches at the same instant just to be able to group commits
by timestamp. Using the trail left by cherry-pick -x is much better. You
can just commit your changes to master and cherry-pick them wherever you
want to. This is independent of doing the work in a topic branch.
(Of course, with git it's less troublesome to merge forward rather than
pick backwards, but that's a workflow change that's a lot harder to
adjust to.)
-- ams