Re: [PATCH v3] doc: clarify --follow and log.follow for git log

From: Junio C Hamano <gitster@pobox.com>
Date: May 11, 2026, 00:46 UTC
Message-ID: <xmqqh5oewz6c.fsf@gitster.g>
In-Reply-To: <CAJ-ks9krzLO_+O74omAfeVByUBh=rDGSVSarf5PGwkdWepzubw@mail.gmail.com>

Tamir Duberstein <tamird@gmail.com> writes:

Show 11 quoted lines

>> Undefined behaviour can change without notice, and users should be
>> strongly discouraged from using it.  Describing what the current
>> implementation happens to do moves us exactly in the opposite
>> direction.
>>
>> `--follow` is a checkbox feature. You can use it "only with a single
>> filename on a linear history" or all bets are off otherwise.
>>
>> That is what we should describe if we want to be honest.
>
> At the very least the documentation should state this...?

Sure.

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.