On Fri, Dec 4, 2020 at 1:37 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > >> What we want to see can be done without such backward incompatible > >> changes, e.g. declaring the combination of "--ff-only" and > >> "--[no-]rebase" incompatible and/or the last one wins, I would say, > >> and I suspect Alex's RFC was an attempt to make the first step in > >> that direction. > > > > It's debatable whether or not that is "backwards incompatible". > > > > Currently "--no-rebase --ff-only" fails if the merge is > > non-fast-forward. With the proposed change of semantics it would work. > > That's a change. > > But with such a change, "--ff-only --no-rebase" would work by > ignoring the "I want to reject non-ff situation" request from the > user, no? Yes. And that's a change. That's why the "pull.mode=ff-only" solution is cleaner; it doesn't need --ff-only to change its semantics. > > Keep in mind the whole point of the changes: to make --ff-only the > > default. > > Sorry, I know you keep repeating that "keep in mind", but I do not > quite see why anybody needs to keep that in mind. Has a concensus > that the repurposed --ff-only should be the default been > established? That's the whole point of this patch (pull: default pull.ff to "only" when pull.rebase is not set either). If not --ff-only, then "pull.mode=ff-only". Are you saying making the default be fast-forward merges only is not the eventual end-goal? Cheers. -- Felipe Contreras
