Junio C Hamano wrote:
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.
I've used the --rebase option to git pull, explained it to my co-workers
and also made sure they're using a version of git that has it. So far
there hasn't been a single complaint about "git pull" being any harder
to grok.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
