Linus Torvalds <torvalds@xxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html