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

On Thu, 26 Oct 2006, Jerome Lovy wrote:

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