Re: Managing multiple branches in git

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Managing multiple branches in git
Дата
Msg-id 603c8f070906021900r39d6931doaf7bdfba01a36235@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Managing multiple branches in git  (Mark Mielke <mark@mark.mielke.cc>)
Ответы Re: Managing multiple branches in git  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список pgsql-hackers
On Tue, Jun 2, 2009 at 9:46 PM, Mark Mielke <mark@mark.mielke.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: It's June 1; do you know where your release is?
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Managing multiple branches in git