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

From: Karl Hasselström <kha@treskal.com>
Date: Oct 26, 2006, 17:26 UTC
Message-ID: <20061026172603.GA21256@diana.vm.bytemark.co.uk>
In-Reply-To: <Pine.LNX.4.64.0610261003590.3962@g5.osdl.org>

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

Show 5 quoted lines

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

Show 5 quoted lines

> 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