Re: [PATCH] Documentation/git-bisect.txt: add --no-ff to merge command

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Mihail Atanassov wrote:

> Thanks for the quick turnaround! And apologies in advance for the delayed
> and potentially mangled response, I can't get into my gmail account from
> a sensible MUA...

Interesting.  https://support.google.com/mail/thread/11736136 tells me
there's an issue with Kmail's oauth support.  You might want to get in
touch with the Kmail authors, or, as a fallback, use an application
specific password or other mail client.

[...]
> On Sat, 26 Oct 2019 at 03:26, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Hmm.  I think the comment might put a bit too much emphasis on the
>> "how" instead of the "why".
[...]
>> So I'd be tempted to leave the comment ending with "and then attempt a
>> build".
>
> Fair point, I actually did spend a bit of time on the fence between your
> suggestion and what I ultimately submitted. I ended up expanding on it
> precisely because the '--no-ff' seems a bit arbitrary to the casual observer
> and requires cross-referencing other documentation (which is how I figured
> out I ought to produce this patch :)).
>
> I can't think of any wording that would be any better, so I'll push a v2 with
> no comment changes, and leave it to the reader's curiosity (or lack thereof).

Thanks, that sounds good to me.

As an orthogonal point, I wonder whether we can start the multi-step
migration of making --no-commit imply --no-ff by default:

 1. Act as --ff when --no-commit is passed without --ff or --no-ff
    (the state today)

 2. Warn when performing a fast-forward merge and --no-commit was
    passed without --ff or --no-ff

 3. Error out instead of performing a fast-forward merge when
    --no-commit is passed without --ff or --no-ff

 4. Warn and refuse to perform a fast-forward merge when --no-commit
    is passed without --ff or --no-ff

 5. Refuse to perform a fast-forward merge with --no-commit is passed
    without --ff or --no-ff, just as though --no-ff were passed.

(A config setting could allow people to get the futuristic behavior
early.  And it might be possible to skip some steps. :))

[...]
>>> -if   git merge --no-commit hot-fix &&
>>> +if   git merge --no-commit --no-ff hot-fix &&
>>
>> Good.

This part still looks like a good change to me. :)

Sincerely,
Jonathan