Re: Managing multiple branches in git

On Tue, Jun 2, 2009 at 3:38 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> What *really* bugs me is that it's so difficult to have one "pulled"
> tree and create a bunch of checked out copies from that.

Yeah. It basically doesn't work, hacks to the contrary on this thread
nonwithstanding, and I'm sympathetic to Tom's pain as I spend a fair
amount of time switching branches, doing git-clean -dfx && configure
&& make check && make install.

Of course in my cases they are usually private branches rather than
back branches, but the problem is the same.

And, unfortunately, I'm not sure there's a good solution. Tom could
create 1 local repository cloned from the origin and then N-1 copies
cloned with --local from that one, but this sort of defeats the
purpose of using git, because now if he commits a change to one of
them and then wants to apply that change to each back branch, he's got
to fetch that change on each one, cherry-pick it, make his changes,
commit, and then push it back to his main repository. Some of this
could probably be automated using scripts and post-commit hooks, but
even so it's a nuisance, and if you ever want to reset or rebase
(before pushing to origin, of course) it gets even more annoying.

I wonder whether it would help with this problem if we had a way to
locate the build products outside the tree, and maybe fix things up so
that you can make the build products go to a different location
depending on which branch you're on. I personally find it incredibly
convenient to be able to check out a different branch without losing
track of "where I am" in the tree. So if I'm in
$HOME/pgsql-git/src/backend/commands and I switch to a new branch, I'm
still in that same directory, versus having to cd around. So in
general I find the git way of doing things to be very convenient, but
needing to rebuild all the intermediates sucks.

...Robert