Re: [PATCH v2] Teach 'git pull' about --rebase

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

What I'm really most worried about isn't the commandline switch but the
config option--it makes the same commandlines silently behave in very
different ways.

I really don't want every tutorial that mentions "git pull" to have to
say "the following applies only if git.<current-branch>.rebase is
false".  And it'll be either that or risk having a lot of people saying
"I typed in exactly that commandline, but this happened....".

A default to "false" does at least require positive acknowledgement, but
if this is expected to be used by newbies, they're going to be told to
set that config before they understand the difference it makes.

--b.