On Tue, Nov 24, 2020 at 01:48:56AM -0600, Felipe Contreras wrote: > > 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. > > 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. > 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
