From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Managing multiple branches in git |
Date: | 2009-06-03 02:00:54 |
Message-ID: | 603c8f070906021900r39d6931doaf7bdfba01a36235@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 2, 2009 at 9:46 PM, Mark Mielke <mark(at)mark(dot)mielke(dot)cc> wrote:
> Tom Lane wrote:
>>
>> I can't escape the feeling that we're missing something basic here.
>> It's allegedly one of git's great strengths that it allows you to easily
>> and quickly switch your attention among multiple development branches.
>> Well, so it does, if you haven't got any derived files to rebuild.
>> But rebuilding the Linux kernel is hardly a zero-cost operation,
>> so how have Linus and co failed to notice this problem? There
>> must be some trick they're using that I haven't heard about, or
>> they'd not be nearly so pleased with git.
>>
>
> If git has a real weakness - it's that it offer too many workflows, and this
> just results in confusion and everybody coming up with their own way to
> build the pyramid. :-)
True.
> From reading this thread, there are things that you guys do that I am not
> familiar with. Not to say there isn't good reasons for what you do, but it
> means that I can only guess and throw suggestions at you, where you might be
> looking for an authoritative answer. :-)
>
> "git" has a "git stash" command that I've used to accomplish something like
> what you describe above. That is, I find myself in mid-work, I want to save
> the current working copy away and start "fresh" from a different context.
> Here is the beginning of the description for it:
That doesn't really solve Tom's problem with build intermediates...
> I believe using a repository per release is a common workflow. If you access
> the Linux git repos, you'll find that Linus has a Linux 2.6 repo available.
> However, I think you are talking about using branches for far more than just
> the release stream you are working towards. Each of your sub-systems is in a
> different branch? That seems a bit insane, and your email suggesting these
> be different directories in the working copy seemed a lot more sane to me,
> but then somebody else responded that this was a bad idea, so I pull out of
> the "is this a good idea or not?" debate. :-)
No, the subsystems are not different branches. But the 7.4.x series
of releases is in a branch called REL7_4_STABLE, 8.0.x is
REL8_0_STABLE, etc. Tom often commits a fix to CVS HEAD and then
backpatches to 1-4 previous releases, to be distributed as part of a
subsequent minor release for that branch.
The problem with making each release a separate directory is that,
just like using separate repositories, it will defeat one of the main
strengths of git, which is the ability to move around commits easily.
git-new-workdir is the only solution to the problem of having multiple
branches checked out simultaneously that seems like it might not
suffer from that weakness.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-06-03 04:44:46 | Re: A humble request |
Previous Message | Andrew Dunstan | 2009-06-03 01:59:55 | Re: It's June 1; do you know where your release is? |