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>