Re: Multi-branch committing in git, revisited - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: Multi-branch committing in git, revisited
Date
Msg-id 20100922104407.GA3822@toroid.org
Whole thread Raw
In response to Multi-branch committing in git, revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Compute the number of tuples in a block
Next
From: Itagaki Takahiro
Date:
Subject: Re: Per-column collation, work in progress