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

From Bruce Momjian
Subject Re: Multi-branch committing in git, revisited
Date
Msg-id 201009220301.o8M31LS06572@momjian.us
Whole thread Raw
In response to Re: Multi-branch committing in git, revisited  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Multi-branch committing in git, revisited
List pgsql-hackers
David E. Wheeler wrote:
> On Sep 21, 2010, at 6:20 PM, Tom Lane wrote:
> 
> > While this isn't much worse than what I was used to with CVS, it's
> > definitely not better.  I think that I could simplify transferring the
> > patch back to older branches if I could use git cherry-pick.  However,
> > that only works on already-committed patches.  If I commit in master
> > before I start working on 9.0, and so on back, then the commits will be
> > separated in time by a significant amount, thus destroying any chance of
> > having git_topo_order recognize them as related.  So we're back up
> > against the problem of git not really understanding the relationships of
> > patches in different branches.
> 
> You could commit in each one as you go, cherry-pick, and then in each one
> 
>     git reset --soft HEAD^
> 
> Then they'd all be patched and staged.

If I understand correctly, that 'git reset' will mark all branch changes
as staged but not committed, and then you can commit all branches at
once and push it.  Is that right?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Pei He
Date:
Subject: Re: Get the offset of a tuple inside a table
Next
From: David Christensen
Date:
Subject: Re: Multi-branch committing in git, revisited