On 10/1/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > This would give a handier shortcut iff the rebase goes well, but > the workflow after stopping would be entirely different from the > normal "merge". I am a bit worried about it giving confusion to > the end users. Thanks for the ample feedback, you raise a number of interesting issues. I am wondering now if making rebase a merge strategy is really a good idea. Rebasing is not merging, a difference that could perhaps be overlooked in the no-conflict scenario, but as you point out, is glaringly obvious as soon as you have conflicts. I'm happy to try to address the issues you raised, but I wonder if we would do better to look back at my original proposal which was to add a --rebase option to git-pull. git-pull is the main place there I see need for using a rebase instead of a merge, as anywhere where you might use git-merge directly, if what you really want is a rebase, you can just run git-rebase. -Tom - 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
