Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > And in particular -- this being the original topic of the thread -- > when an svn user sees me doing that, they do not immediately think of > the fact that merging between immutable revisions may have some > benefits. They see me typing four commands (commit, fetch, rebase, > reset) to do the same thing they can do in one command with svn, and > conclude that git is harder to use. No arguments there. While I know I will never use such a workflow myself, I think it makes sense to _allow_ local changes to be merged to the new revision if the user chooses to use such a workflow. The necessary places to change are limited to the Porcelain-ish layer, and adding '-m' option to "git pull", just like "git checkout" has the corresponding option to allow merging local changes, should not be a rocket science. In fact, I vaguely recall keeping a couple of patches to do so in 'pu' several months ago, perhaps for a few weeks. Maybe git has matured too much. In earlier days, people complained about lack of features and existence of misfeatures, and bashed the maintainer with patches. These days, the bashing is done with more words and less patches. - 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