Re: Managing multiple branches in git

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

In response to

Responses

Browse pgsql-hackers by date

  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?