Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > So my rationale was: if we already have an existing framework to integrate > remote changes with our current branch, why not just go ahead and use it? > That's the reason BTW why I originally wanted a "rebase" merge stragegy. > Even if it is not technically a merge. > > I really rather have no user-friendly support for fetch+rebase (and utter > a friendly, but loud curse everytime I made a "git pull" by mistake) than > yet another command. I suspect that people who do not like the two modes of checkout will certainly not appreciate the overloading two behaviours to create different kind of histories and two different ways to continue when the integration do not go smoothly upon conflicts these two behaviours have. However, I agree very much with an earlier comment made by Daniel about our UI being task oriented instead of being command oriented, and I actually consider it a good thing. So it does not bother me too much that "git pull --rebase" has a quite different workflow from the regular "merge" kind of pull. So let's queue "pull --rebase" and see what happens. - 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
