Björn Steinbrink <B.Steinbrink@xxxxxx> writes: > ... If so, it does a "git checkout --merge > <upstream>" (possibly leaving conflicts for the uncommitted changes, > just like "svn update"). Up to this point I was reading with quite a lot of interest. But here I strongly disagree to the point of getting actually disgusted. "svn up" is one of the areas Subversion folks failed to make their system a better CVS. It has the same "local changes are lost in the merge conflict mess in an irreversible way" failure mode, and we shouldn't be making it easy to new people. It is not something we should emulate. You can and should instead refuse the update, and suggest committing first so that the user has a safe record of what he has done and the merge with upstream can be retried if necessary. As you need to have that "refuse but guide the lost soul by telling what to do" mode anyway when... > ... If a fast-forward is not possible, it > complains, telling the user that he needs to use "git merge/rebase/pull" > instead, and might want to create a branch head, in case of a detached > HEAD. -- 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