Re: Buggy `git log -- path` behavior
- From
- Matthew DeVore <matvore@pobox.com>
- Date
- Mar 17, 2023, 16:46 UTC
- Message-ID
- <ae193764-daf2-4fff-89cf-39396f420cb3@app.fastmail.com>
- In-Reply-To
- <ZBH7Uiv7fH9UnB4v@coredump.intra.peff.net>
On Wed, Mar 15, 2023, at 12:07, Jeff King wrote:
Show 13 quoted lines
> I think what you're seeing is the correct output, though, due to history
> simplification. Along the first-parent history, for example,
> Documentation/vm/pagemap.rst never existed. And so since it does not
> exist now, we prune any side branches where it did (because they did not
> lead to the current state; the other side of the merge resolution did).
>
> Tracking down the exact sequence of merges is tricky ("git log --graph"
> is unreadably huge here). But it looks like the file was added by
> ad56b738c5dd (docs/vm: rename documentation files to .rst, 2018-03-21).
> That was merged into docs-next via 24844fd33945 (Merge branch 'mm-rst'
> into docs-next, 2018-04-16), which then eventually moved it in
> 1ad1335dc586 (docs/admin-guide/mm: start moving here files from
> Documentation/vm, 2018-04-18).This was thought-provoking. ad56b738c5dd is a side-branch. I expected a path filter to find changes since git log would show this commit when invoked with no other args.
But the only reason git follows the side branch in the filterless or 'pagemap.*' case is because git sees pagemap.txt (matching the glob) in the first-parent line being removed when the side branch is merged into this first-parent line.
As I usually use --name-status as a default in my workflow, I was surprised git log couldn't find something that grep could :)
Thank you for the thorough explanation despite my terse complaint.