Junio C Hamano wrote: > But recording the merge to have parents <Z C> does not give us > "the first-parent is the trunk" worldview, in the presense of B. > We would prefer to end up with a history more like this: > > -----A ----O > \ \ > X---Y---Z---B'--C' > > so that your work, your contribution with two commits of yours, > was to merge the work done on a side branch and then made one > commit directly on top of it.
Yes, _ideally_, but as it has been explained multiple times most Git beginners have no idea what is a rebase. We might evenaully do this by default, but first we should start rejecting the update by default and recommending `git update --merge` as it has been discussed quite a lot should be the behavior of `git pull`. > Hence, I think the ideal behaviour of the new command is to > replay the first-parent history on top of the updated tip of your > upstream (which by the way is different from how "rebase > --preserve-merges" works; it is more like how J6t wanted to make > "rebase --preserve-merges" work, IIRC). What is the difference with 'rebase -p'? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
