While working on a tool that determines relevant history for a given commit from a previous export, I found a rather odd behavior in git log and I can't seem to pin down what's happening. I'm hoping someone can help explain the behavior.
I've created the following commit graph, and I have two separate workspaces in the same repo. Workspace A has a single file updated in every single commit listed except for E and I which are simple merges (for example git merge bar created commit I). Workspace B, on the other hand, has only had files changed in commits A and L.
When I run git log --name-only --oneline -- workspaceA I get commit 'I' listed, but there are no files affected:
b7faf96 (HEAD -\> main) Commit I
a3c265e Commit H
workspaceA/H
e03be40 (bar) Commit L
workspaceA/L
7ead348 Commit G
workspaceA/G
7b80d8d (tag: workspaceA-2020.0.2.0, baz) Commit B
workspaceA/B
d383bfa Commit F
workspaceA/F
6d2b8a4 (tag: workspaceB-2020.0.1.0, tag: workspaceA-2020.0.1.0) Commit A
workspaceA/A
...
Note that this list contains Commit 'I' but it has no files listed under the commit.
Now, when I run git log --name-only --oneline -- workspaceB I get a list that doesn't contain commit 'I' at all:
e03be40 (bar) Commit L
workspaceB/L
6d2b8a4 (tag: workspaceB-2020.0.1.0, tag: workspaceA-2020.0.1.0) Commit A
workspaceB/A
...
My problem is that there isn't any consistency in whether commit 'I' shows up, even though none of the files were actually changed during the merge which created commit 'I'. Can anyone explain why this is happening?
This doesn't meet my expectations because I can't see why commit 'I' only shows up when filtering for one folder and not the other, even though the merge involves changes to both folders as seen in my screenshot.