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

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 26 Oct 2006, Jerome Lovy wrote:
> 
> Could someone please point me to / give me the rationale for the "Never commit
> to the right side of a Pull line" rule ?

It's not a technical rule per se.

It's just a way to avoid what will almost inevitably otherwise be a 
horribly horribly confusing situation.

I say "almost inevitably", because if you really have worked with git 
enough, and understand how it works on a very fundamental level, there are 
actually no problems at all with doing so, and maybe you could have 
perfectly fine reasons to break the rule, and commit to a branch that is 
officially "maintained in another repository" and then push it out.

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.

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