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 local modifications 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 <m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
