Re: git bug? + question

From: Junio C Hamano <junkio@cox.net>
Date: Nov 3, 2006, 02:40 UTC
Message-ID: <7v4pthmew1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <buoejsme6ho.fsf@dhapc248.dev.necel.com>

Miles Bader <miles.bader@necel.com> 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 <kha@treskal.com> writes:

Show 21 quoted lines

> On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:
>
>> 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.
>
>> 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.