From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 11 May 2026 02:06:24 GMT
Subject: Re: [PATCH v3] doc: clarify --follow and log.follow for git log
Message-ID: <xmqqwlxavgwv.fsf@gitster.g>
In-Reply-To: <CAJ-ks9n=DcwqyP7K_q0Ki6_3_+o5=558FK1DKr0+VyiM7q69EA@mail.gmail.com>

Tamir Duberstein <tamird@gmail.com> writes:

>> Doesn't the current text for the option
>>
>>         `--follow`::
>>                 Continue listing the history of a file beyond renames
>>                 (works only for a single file).
>>
>> pretty much cover that, though?  The configuration side is a bit
>> more verbose but essentially says the same thing, I think.
>>
>>         `log.follow`::
>>                 If `true`, `git log` will act as if the `--follow` option was used when
>>                 a single <path> is given.  This has the same limitations as `--follow`,
>>                 i.e. it cannot be used to follow multiple files and does not work well
>>                 on non-linear history.
>>
>> We do not say anything about what the feature happens to do when it
>> is given a non-linear history whose branches each rename to the same
>> final name that you start following from in the more recent part of
>> the history, either, and stop at saying "does not work well".  We
>> should treat that case the same way as the case where the user gives
>> a pathspec with multiple pathspec elements or a pathspec that
>> matches with a directory.
>
> Sorry, I was unclear. I was saying that the documentation should be
> explicit about the cases that constitute "undefined behavior".

Ah, I see.

I am not sure.  This is not the only case where we have left these
unspecified things unsaid, is it?  I am not sure if it is worth
singling out this particular case.

Thanks.