From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Managing multiple branches in git |
Date: | 2009-06-02 23:13:56 |
Message-ID: | 21012.1243984436@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jun 2, 2009, at 3:56 PM, Tom Lane wrote:
>> Meanwhile, there seem to have been ten different solutions proposed to
>> the problem of working with multiple branches/checkouts, and I plead
>> confusion. Anyone want to try to sort out the pluses and minuses?
> If the whole purpose of you committing all backpatches to CVS in a
> single commit is to get a simpler cvs2cl history, you can easily do
> that with a single clone of the entire history in Git, commit each
> branch separately but with the same commit message, and then, yeah,
> someone will be able to provide a report that filters out the
> duplicate messages appropriately, I have little doubt.
I think you missed the part of the discussion about not wishing to share
a single working directory across all the branches. The time to rebuild
derived files whenever I switch branches is simply too great with that
approach. I want a working copy per branch, and some
not-impossibly-complicated scheme for managing the pulls/commits/pushes
given that environment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-06-02 23:22:42 | Re: Managing multiple branches in git |
Previous Message | Joe Conway | 2009-06-02 23:08:18 | Re: dblink patches for comment |