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

quoted text
> 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 text
> 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. :-)

It feels like the right thing to do, because it reduces the amount of
things a user has to know about git internals. Until you get to the
level where you can do brain surgery on your repo, the remotes/
branches will really _be_ your local read-only mirror of remote
branches, and you don't have to be aware of the possibility that they
could get out of sync because of local commits.

-- 
Karl Hasselstr