Re: Managing multiple branches in git

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. :-)
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:

DESCRIPTION      Use git stash when you want to record the current state of the 
working      directory and the index, but want to go back to a clean working      directory. The command saves your
localmodifications away and 
 
reverts      the working directory to match the HEAD commit.

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. :-)

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>