Re: Dangers of working on a tracking branch

[Nicolas Pitre <nico@cam.org>]

On Thu, 15 Feb 2007, Bill Lear wrote:

> On Thursday, February 15, 2007 at 16:00:23 (-0500) Nicolas Pitre writes:
> >On Thu, 15 Feb 2007, Bill Lear wrote:
> >
> >> We are about to switch to git 1.5 from git 1.4.4.1.  I cannot remember
> >> if someone posted about this, but what is the danger of working on a
> >> tracking branch --- there are abundant cautions about doing this, but
> >> I can't recall and can't find the reason this is bad.
> >
> >A tracking branch is supposed to be a local mirror of what is available 
> >remotely.  If you commit local changes to it then you break that model.
> 
> Ok, so I break the model, what is the harm in that?  Can I no longer
> pull from or push to the remote branch?  Do I corrupt something
> locally?  Does something else break?  I'm trying to formulate an
> explanation to our users why the 1.5 way is superior and I can't just
> say "if you do that you break the model".

If you commit on top of a tracking branch, then you won't be ablt to 
update that branch with remote changes because the tracking branch will 
contain local changes that the remote doesn't have.  In other words, the 
remote end won't be able to determine the set of changes you are 
missing to send you only those missing changes.

At that point it is still possible to do the reverse, i.e. push your 
local changes to the remote then both local and remote branches will be 
in sync.  But that works only if the remote was not updated by someone 
else.  If the remote was updated by someone else, then you fall into the 
same situation as if you committed on top of a tracking branch and you 
try to fetch, because it is then impossible for you to determine what 
the remote is lacking since you won't find the remote changes in your 
local repository.  You are then stuck in a dead lock.

Now there is of course a way to force a push or a fetch even if the 
above scenarios occur.  But if you force the push then the remote 
changes that you don't have will be lost.  If you force a fetch then 
your local changes that the remote doesn't have will be lost.

This is why it is better to have a tracking branch that is modified only 
by fetching remote changes only.  When you make a local copy of that 
branch and commit changes to that work branch, then you can push those 
changes to update the remote branch.  And if the remote branch has 
changed then you have the possibility of updating the tracking branch 
with the remote changes you don't have yet, merge them into your local 
copy with your work, and reattempt the push.  But that works fine only 
if the tracking branch is always a subset of what the remote has.


Nicolas