Re: [PATCH v3] doc: clarify --follow and log.follow for git log
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 11, 2026, 02:06 UTC
- 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:
Show 25 quoted lines
>> 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.