Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > So I like pull.mode in that sense. But it is also weighed against the > > fact that we'd still have to support pull.rebase, and we'd still have to > > support pull.ff, and explain how those interact with pull.mode (and I > > think any new error in this area must be squelched by those existing > > variables, or it would be a regression for people who already picked > > their default long ago). > > I agree that if we were starting from scratch, things would have > been much simpler; choose among three ways to reconcile histories > (merge, rebase, or ff-only), without adding --[no-]rebase, and allow > --[no-]ff only when merging (i.e. things like --ff-only --ff, > --no-ff --rebase, would be nonsense combinations). The additional > complexity of introducing pull.mode is the primary thing I am > hesitant to support it, as we have to design and explain how > existing knobs interact with newer one. I have already tried all the options. If we go through a deprecation period (which I insist we must), the options are these: 1. Change the semantics of --ff-only (breaks backwards-compatibility) 2. Add a "pull.rebase=ff-only" option (very weird) 3. Add a "pull.mode" configuration (tons of advantages) Yes, we have to map the modes to the existing knobs, but it's not complex: * pull.rebase = false <=> pull.mode = merge * pull.rebase = true <=> pull.mode = rebase * pull.rebase = * -> pull.mode = rebase That's it. We don't even have to map --ff-only (which has different semantics anyway). Cheers. -- Felipe Contreras
