Git-History of a file, that was modified by git merge -s subtree

Question

How can I get git log to show me the entire history of a file when even git log -M --follow --full-history new/directory/file failed.

But first a bit of context on the changes not showing...

We imported a git repository inside another one, we proceeded like so:

git clone git@domain.com:namespace/NewRepository
cd NewRepository
git remote add oldRepository git@domain.com:oldNamespace/oldRepository.git
git fetch oldRepository
git checkout -b old-master oldRepository/master
mkdir -p new/directory/
git mv -k * new/directory/
find . -name ".*" -d 1 -exec git mv -k {} new/directory/ \;
git commit -m "Move oldRepository to its new location"
git push --set-upstream origin old-master
git checkout master
git pull
git merge old-master --allow-unrelated-histories
git push

So far so good, after this a git log --follow new/directory/file would give me the complete changelog of the file.

About a week later, some new changes to the old repository needed to be "pulled" into the new one. We proceeded like so:

git fetch --all
git checkout old-master; 
git merge origin/old-master; # I got no conflict (No change actually)
git merge origin/master; # I got no conflict (As expected)

git merge -s subtree -X patience oldRepository/master; 
# I am not sure "-X patience" is a thing but that's what we ran.
# But the "-s subtree" is the important part I believe, we got no conflict and all expected changes were found in their new location (Even newly created files)

git push --set-upstream origin old-master

I then created a PR, and then eventually merged it, using the create a merge commit option.

Now if I do git log --follow new/directory/file the latest commit I see is: Move old repository to its new location , but I do not get any newer entry from the old repository that was done after the original import. Despite the changes being present in the file.

However:

• A git blame new/directory/file does show me next to the modified line the proper info
• A git log (With no file specified) does show me the commit
• A show history in my IDE does show me the log entry.

Since my IDE does it, I am guessing there is a combination of flags for git log to show me the proper history, but I tried A LOT of combination and could not figure out. And yes I did read the man page...

Additionally, if a different procedure could have prevented me to get into this situation I would like to know... Doe in retrospect maybe the old-master branch was unnecessary, but originally it seemed like a good idea to have a branch to resolve conflict.

Thanks!

Answer 1

If the merge commit did not introduce extra modifications on the target file, git log new/directory/file will not display the merge commit itself (which may be a bit disturbing), and depending on the order it chooses to display the commits, the commits from your old-master branch may be further down the log list.

Try adding the --graph option:

git log --graph --follow new/directory/file
# or
git log --graph --oneline --follow new/directory/file

and see if you have a clearer view of the commits that modified that file.

You may also try the --date-order , --author-date-order and --topo-order flags.

---

[edit] when I first read your question, I somehow thought that the new/directory was also created and pushed on oldRepository . So I inferred the modifications in oldRepository were applied to new/directory/file , and I found thus surprising that git would not list the history of new/directory/file .

I now understand that, in oldRepository , the path to file is /file , and that including the new commits as part of git log --follow new/directory/file relies on git heuristics to find renames.

Regarding options in git log , have you tried:

• using -C and --find-copies-harder ?
• setting a lower detection threshold using -M ? (default is 50%, -M40% for example)?
• if crlf line endings were to differ between the two repos: --ignore-cr-at-eol ?
• setting options to ignore whitespace changes: --ignore-whitespace-at-eol or -b ?

Regarding "renaming" in git: you certainly are aware that git does not track renaming in its history, it just tracks the content you tell it to store.
When it displays a "renaming" in git log or git status or... it actually tries to guess what files could have been renamed be looking at the diff between the global content. The -M50% option, for example, says that it will consider that file B was possibly "moved" from file A if 50% of the files are the same.