Re: [PATCH v2] doc: git-log: clarify --follow options
- From
Tamir Duberstein <tamird@gmail.com>
- Date
- May 10, 2026, 23:51 UTC
- Message-ID
- <CAJ-ks9nVaq-hMC1MoiiUTxnP6_TZLteL+Ri4x-OKsx4FXkq4hA@mail.gmail.com>
- In-Reply-To
- <xmqqqzni967o.fsf@gitster.g>
On Sun, May 10, 2026 at 7:48 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 16 quoted lines
> > Tamir Duberstein <tamird@gmail.com> writes: > > > I will reroll to say that `--follow` follows a single file beyond renames, works > > only with exactly one pathspec, and that directory pathspecs do not follow > > directory renames even though they still use the same traversal mode and can > > therefore show a different set of commits. I will also fix the subject and > > option ordering as suggested. > > To be quite honest, the "--follow" option being what it is (i.e., a > checkbox option to claim we do support such an operation, without a > serious design and implementation), I'd rather see our documentation > being more honest and do not claim it works with pathspec at all. > When you use "--follow", you have to give a single filename, and > that file is followed across commits that renames it from some other > name, and then that file with the old name is followed.
I certainly agree that being honest is the right thing to do - but the honest truth is that `--follow` changes the behavior when used with *any* pathspec, not just when given a single file. I attempted to capture that nuance in v3.
Show 6 quoted lines
> > If multiple histories are merged and if the file being followed > turns out to have come from different files on these different > histories, the "old name" the traversal is currently following is > not kept track of per traversal path, so we cannot expect the > feature to work with anything but a linear history, either.
I'm not sure how to reply to this. The ground truth today is that the option does have an effect when used with not-just-a-single-file, yet the documentation does not mention this at all.