Re: git bug? + question

Miles Bader [off-list ref] writes:

Also, a question:  Is there anyway to make git-clone use
--use-separate-remote by default?  I'm trying for a "lots of branches in
a single shared remote repository" style, and use-separate-remote seems
more sane for this usage.

This was suggested last week on the list, and I think it is a
sensible thing to do.

Karl Hasselström [off-list ref] writes:

On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:

quoted

But it's a good rule in general, just because it makes a certain
common workflow explicit. In fact, we really probably should start
to always use the "refs/remote/origin/HEAD" kind of syntax by
default, where you can't even _switch_ to the branch maintained in
the remote repository, because it's not a real branch locally.

Seconded. I really like having remote branches in their own namespace
where I can't confuse them with my local branches by mistake -- and
that the branches of different remotes end up in different separate
namespaces.

quoted

So normally you should consider the "origin" branch to be a pointer
to WHAT YOU FETCHED LAST - and that implies that you shouldn't
commit to it, because then it loses that meaning (now it's "what you
fetched last and then committed your own work on top of", which is
something totally different).

Defaulting to --use-separate-remotes would mean not having to explain
this to every single confused new user. :-)

The only downside that I can think of is that it affects me or
anybody who works on more than one machine on multiple branches
slightly negatively.

I know I keep "master" checked out on my secondary machines when
I am done working there, so the mapping origin:master,
maint:maint, next:next, and +pu:pu I get by default has been
easy for me to work on.  With the current layout, updating and
building four variants can be done with:

	git pull
        for b in master maint next pu
        do
        	git checkout $b && make || break
	done

which is efficient (guaranteed to do only one fetch from remote)
and convenient.  Also I have Push: mapping set up on my
main machine to do master:origin, next:next, maint:maint, and
+pu:pu so that I can replace the first "git pull" on the
secondary machine with "git push secondary" on my main machine.

With separate remotes, I'd need something like:

	for b in master maint next pu
        do
        	git checkout $b && git pull && make || break
	done

And I also would need to have per-branch configuration to merge
from ". remotes/origin/$b" without re-fetching while on a
non-master branch $b, for the above to work.  I still need to
remember to process "master" first, so all things considered,
this is a regression in usability for my workflow.

But that is probably a minor inconvenience to a minority.  Most
of the world follow others' repositories that have a single
primary head, and defaulting to use separate-remote would help
them a lot.

So I am in favor of the change, but this is not something we can
do in a flag-day fashion.  We would probably need updating the
tutorial and the documentation first.