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

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 ?

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

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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

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

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 ?

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

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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