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

Hi,

Could someone please point me to / give me the rationale for the "Never commit to the right side of a Pull line" rule ?

I found the rule in the second Note of the git-fetch man-page (eg http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).

It's been taken over in _bold letters_ by X.Org/freedesktop.org in their "UsingGit" document (http://freedesktop.org/wiki/UsingGit).

In both places though, I don't see any explanation, but rather a commandment ;-) . Am I missing the ovious ?

My candid thoughts: to me the practice recommended here seems subjectively "cleaner" indeed, but is it objectively better or even essential? Why?

TIA Jérôme

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

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

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.

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.

Jerome Lovy wrote:

Because git refuses to fetch into branch on top of which there are changes which are not present in the branch you fetch from (if it is not fast-forward case). So commitiing to tracking branches breaks the most typical workflow, i.e. fetch when you want, push when you are ready.

git-clone --use-separate-remotes takes care of that by putting tracking branches in refs/remotes/, i.e. outside refs/heads/, so you cannot commit there, at least not by accident.

--- Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> wrote:

Yes, you are missing the obvious and yes it is explained. Read the 2nd "Note" for the documentation of "git-fetch":

http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html

Quoted here for convenience:

[NOTE] You never do your own development on branches that appear on the right hand side of a <refspec> colon on `Pull:` lines; they are to be updated by `git-fetch`. If you intend to do development derived from a remote branch `B`, have a `Pull:` line to track it (i.e. `Pull: B:remote-B`), and have a separate branch `my-B` to do your development on top of it. The latter is created by `git branch my-B remote-B` (or its equivalent `git checkout -b my-B remote-B`). Run `git fetch` to keep track of the progress of the remote side, and when you see something new on the remote branch, merge it into your development branch with `git pull . remote-B`, while you are on `my-B` branch. The common `Pull: master:origin` mapping of a remote `master` branch to a local `origin` branch, which is then merged to a local development branch, again typically named `master`, is made when you run `git clone` for you to follow this pattern.

  Luben