Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
> >> We do not have to or implement both, but either should give us the
> >> "when pull sees a non-ff history, it should stop without merging or
> >> rebasing, and the user won't be given the advice on how to choose
> >> between merge and rebase" behaviour, I would think.
> >
> > Right, so both should error out.
>
> One of them, not both; the one we choose to implement would make it
> fail, I would think.
If only one of them fail, then it's impossible to tell the user:
If you want to try the new behavior, type this command:
git config $something
We have to go straight for the error, with no deprecation period.
> > And what should these do?
> >
> > git -c pull.rebase=no -c pull.ff=only pull --merge
>
> There is no --merge, so let's reread with s/--merge/--no-rebase/;
Back in 2013 everyone found it easier to speak in terms of --merge, even
you, BTW, who was the first one to send a patch with --merge [1], after
Linus suggested it [2].
> the command line would be saying "I only want to fast-forward, or I
> want the command to fail". The advice code should not trigger
> (i.e. we gave an explicit preference to merge and not to rebase, so
> rebase_unspecified would be false), but the configured preference
> that says "we take only fast-forward merges" will still be in effect.
> If the history is fast-forward, the merge backend will happily
> advance our history. If not, the merge backend will happily fail
> the pull.
>
> If you want to countermand the configured preference from the
> command line and allow a merge to be done when non-ff history is
> given, what you'd need to override is not --merge/--no-rebase. The
> configuration pull.rebase=no already says you do not want rebase and
> you want merge). You want to override --ff-only, so I'd expect
> "pull --ff" (or "pull --no-ff") to be how you override your
> configured preference and merge in a non-ff history, either by fast
> forwarding or creating an extra merge commit.
Precisely, so you can't tell the user:
If you want to try the new behavior, type this command:
git config pull.ff only
Because, after the user gets the error:
Not a fast-forward, either merge or rebase.
She cannot do:
git pull --merge
Which is the best idiom to specify she wants a merge.
The command will still fail, even after the user has specified she wants
the new mode, and that she wants to merge in this perticular case.
> > git -c advice.pullnonff=false pull --merge
>
> Again with s/--merge/--no-rebase/; but that is showing the
> preference not to rebase and to merge from the command line, so
> shouldn't it just go ahead and merge without any advice?
Yes, but *before* we make this the default, what configuration get us
there today?
> > I'm going to answer because I think it's obvious what you would expect:
> > if you pass --merge, both should succeed.
> >
> > Except they won't, because "git pull --ff-only --merge" fails.
> >
> > Correct?
>
> See above.
That's a "correct". There's no configuration today that gives us both:
1. fail: git -c $config pull
2. pass: git -c $config pull --merge
Like this does:
1. fail: git -c pull.mode=fast-forward pull
2. pass: git -c pull.mode=fast-forward pull --merge
Cheers.
[1] https://lore.kernel.org/git/7v4ncjs5az.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/git/CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@xxxxxxxxxxxxxx/
--
Felipe Contreras
