Re: Multi-branch committing in git, revisited

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Multi-branch committing in git, revisited
Date: 2010-09-22 03:01:21
Message-ID: 201009220301.o8M31LS06572@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-09-22 03:02:53 Re: Multi-branch committing in git, revisited
Previous Message Pei He 2010-09-22 02:58:49 Re: Get the offset of a tuple inside a table