From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Managing multiple branches in git |
Date: | 2009-06-02 20:32:26 |
Message-ID: | 18188.1243974746@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I wonder whether it would help with this problem if we had a way to
> locate the build products outside the tree, and maybe fix things up so
> that you can make the build products go to a different location
> depending on which branch you're on.
I'm beginning to seriously consider the idea that the git repository
should think each branch is a separate directory subtree --- ie,
completely abandon the notion that git is worth anything at all for
managing multi-branch patches. If we have HEAD, REL8_3, etc as
separate subtrees then we can easily have a single commit touching
multiple branches in whatever way we want.
The arguments that were put forward for switching to git all had to do
with managing patches against HEAD. AFAIK hardly anyone but the core
committers deals with back-patching at all, and so a structure like this
isn't going to affect anyone else --- you'd just ignore the back-branch
directory subtrees in your checkout.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-02 20:36:50 | Re: Locks on temp table and PREPARE |
Previous Message | Mark Mielke | 2009-06-02 20:30:58 | Re: Managing multiple branches in git |