Buggy `git log -- path` behavior

Buggy `git log -- path` behavior

[Matthew DeVore]

Hello,

I think the below terminal session demonstrates a bug in git log. Notice the first git log command gives no output. Any thoughts?

~/src$ git clone http://github.com/torvalds/linux
...
~/src$ cd linux
~/src/linux$ git checkout v5.15
~/src/linux$ cd Documentation/vm
~/src/linux/Documentation/vm$ git log -n2 --name-status --oneline -- pagemap.rst
~/src/linux/Documentation/vm$ git log -n2 --name-status --oneline -- 'pagemap.*'
1ad1335dc586 docs/admin-guide/mm: start moving here files from Documentation/vm
D       Documentation/vm/pagemap.rst
41ea9dd36b6b docs/vm: pagemap: change document title
M       Documentation/vm/pagemap.rst
~/src/linux/Documentation/vm$

Thank you,
Matthew

Re: Buggy `git log -- path` behavior

[Jeff King]

On Wed, Mar 15, 2023 at 11:04:12AM -0500, Matthew DeVore wrote:

> I think the below terminal session demonstrates a bug in git log.
> Notice the first git log command gives no output. Any thoughts?
> 
> ~/src$ git clone http://github.com/torvalds/linux
> ...
> ~/src$ cd linux
> ~/src/linux$ git checkout v5.15
> ~/src/linux$ cd Documentation/vm
> ~/src/linux/Documentation/vm$ git log -n2 --name-status --oneline -- pagemap.rst
> ~/src/linux/Documentation/vm$ git log -n2 --name-status --oneline -- 'pagemap.*'
> 1ad1335dc586 docs/admin-guide/mm: start moving here files from Documentation/vm
> D       Documentation/vm/pagemap.rst
> 41ea9dd36b6b docs/vm: pagemap: change document title
> M       Documentation/vm/pagemap.rst
> ~/src/linux/Documentation/vm$

Interesting case. You didn't say what you think the bug is, but I assume
you expected that the first command should produce those two commits and
it didn't.

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).

So any merges between history containing those commits (where the file
is gone because it went away) and history that didn't have any of them
(where the file never existed) are candidates for simplification, since
the side branch in its total effect didn't contribute to changing the
path.

If you don't want that simplification, use --full-history (though you
probably also want --simplify-merges in this case).

So why does your second command produce output? It's because it matches
pagemap.txt, too. And along that side branch that created and removed
pagemap.rst, there are changes to pagemap.txt (since, after all, it was
converted into pagemap.rst). If you get rid of the "-n2", you'll see
those commits.

-Peff

Re: Buggy `git log -- path` behavior

[Matthew DeVore]

On Wed, Mar 15, 2023, at 12:07, Jeff King wrote:
> 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.