Re: Pick the right default and stop warn on `git pull`

From: Jeff King <peff@peff.net>
Date: Nov 24, 2020, 08:07 UTC
Message-ID: <X7y/OdcoVnBeEVju@coredump.intra.peff.net>
In-Reply-To: <CAMP44s31OqnRnMO3bcO43VyUCP27o8UGPA5ognGi1s8Se+CRiw@mail.gmail.com>

On Tue, Nov 24, 2020 at 01:48:56AM -0600, Felipe Contreras wrote:

Show 9 quoted lines

> > Yep. After reading the first half of your mail, I started to respond
> > with the exact same thing. The key thing is letting the command-line
> > options override all of the related config. But I guess after reading to
> > the end that you don't actually like this. ;)
> 
> Yes, the command-line options should override the configuration, and
> the configuration should override the default.
> 
> I'm not sure what makes you think I wouldn't like that.

I think it's obvious that "--rebase" should override "pull.rebase". But what I thought you were suggesting (and which I think is reasonable) is for "--rebase" to affect pull.ff, as well. That's less clear (and doesn't happen now), but I think could produce sensible semantics.

But it sounded like you thought that was too complicated.

Show 7 quoted lines

> > I do agree it would be more clear in the long run with a single option
> > (config and command-line) that makes it clear the values are mutually
> > exclusive. I'm just not sure if it's painful to get there without
> > breaking compatibility or introducing confusion in the meantime.
> 
> I think it is possible. I did the patches several years ago. And I'm
> working on the patches right now. We'll see.

OK. Then I'm happy to wait and see.

Show 6 quoted lines

> Well, in git-pull there's a callback called: parse_opt_rebase(), and
> if no argument is passed, then it returns REBASE_FALSE (0).
> 
> The rest of the code assumes 0 is no-rebase (i.e. merge).
> 
> There's no REBASE_UNSET.

Right, I meant that you would add one. But if you are pursuing the other option, we can see how that goes.

-Peff