At 2010-09-21 21:20:06 -0400, t...@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 change was cherry-picked
from. Append the note only for cherry picks without conflicts.
Do not use this option if 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 fix to 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
