Re: git pull for update of netdev fails.

[Shawn Pearce <spearce@spearce.org>]

Linus Torvalds <torvalds@osdl.org> wrote:
> The thing is, if you don't understand how rebasing etc destroys history, 
> you may do things like do a "git pull" or a "git merge" of a branch that 
> the other side WILL THROW AWAY! That will later result in major pain, 
> because when you then try to merge it later, you will get all kinds of 
> nasty behaviour, because the history you merged earlier no longer matches 
> the history you're now trying to merge again, and the work you merged 
> earlier is simply not there any more.

Yet people (typically those new to Git) will still pull or merge
the wrong branch in, work on top of that merge, publish it, others
will build on that... and wham; that topic branch head which you
wanted to rebase prior to merging is now wedged 50 commits deep in
your history.

Just yesterday I found such a case in a shared repository.  Now I
have a branch wedged in our shared mainline that I can't get out
and shouldn't have been there in the first place.


If only the shared repository had a way of advising clients that
commits stored in ref 'BAAAD' may not survive and thus shouldn't
be merged.  So that git-merge wouldn't let you merge them in.
Unfortunately there isn't a way to do this that's sane so I'm not
even going to try.


Probably what I should have done (now that I think about it) was to
put a check into our update hook on the shared repository to look for
a rebaseable branch (which are listed in some info file) being pushed
into a non-rebaseable one.  If that happens then abort the update.

Unfortunately our current Git client (1.4.2)/Git server version(1.3.1)
combinations means we get no output from our update hook when it
fails, so I can't tell the newbie what they did wrong.

-- 
Shawn.