Felipe Contreras wrote: > Junio C Hamano wrote: > > "--no-ff --rebase" (in any order) would be a nonsense combination, > > as it asks "please create an extra merge commit even when the > > history fast-forwards, but by the way I do not want merge I want > > rebase" [*1*]. It should error out when the history fast-forwards, > > I think, and it probably should also error out when the history does > > not fast-forward, instead of rebasing. > > But we shoud not imply what the user didn't say. > > Yes, "--no-ff --rebase" is obviously nonsense, but that's a > simplification of setups the user may have, for example: > > git config pull.ff false > git pull --rebase > > Here, I think the user is saying: "please do a rebase, and ignore the > pull.ff configuration". > > But the other way would be: > > git config pull.rebase true > git pull --no-ff > > Following the same logic, the user is saying: "please do a > non-fast-forward [merge], and ignore the pull.rebase configuration". > > Either we imply the merge, or we don't. > > I don't think it makes sense for the code to imply the user did say > --merge, and therefore don't show the advice (or in the future error > out), but then continue as if the user did say --rebase. I didn't see a response to this, but after thinking more about, I think I have a clean solution: just remove all the opt_ff logic altogether. It's clear --ff doesn't imply a merge, so we shouldn't act as if it was. The warning should still be displayed. -- Felipe Contreras
