Re: Managing multiple branches in git - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Managing multiple branches in git |
Date | |
Msg-id | 603c8f070906021900r39d6931doaf7bdfba01a36235@mail.gmail.com Whole thread Raw |
In response to | Re: Managing multiple branches in git (Mark Mielke <mark@mark.mielke.cc>) |
Responses |
Re: Managing multiple branches in git
|
List | 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 by date: