Thread (2 messages) 2 messages, 2 authors, 2020-12-04

Re: [RFC 2/2] pull: default pull.ff to "only" when pull.rebase is not set either

flat view

From: Felipe Contreras <hidden>
Date: 2020-12-04 21:12:43

On Fri, Dec 4, 2020 at 1:37 PM Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help