Miles Bader <miles.bader@xxxxxxxxx> 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@xxxxxxxxxxx> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html