Re: Rationale for the "Never commit to the right side of a Pull line" rule

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

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öm, kha@treskal.com