1

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!

Jonathan Daigle
  • 33
  • 5
  • 1
    Was the file moved at that breaking point? – Lasse V. Karlsen Aug 06 '20 at 20:39
  • (typo) `git --follow` should be `git log --follow`, right ? – LeGEC Aug 07 '20 at 07:50
  • yes, thank you LeGEC – Jonathan Daigle Aug 07 '20 at 17:40
  • "Was the file moved at that breaking point?" Not really the file was moved as part of the original import, from both a different repository but also from its path location from / to /new/directory. However, at the breaking point, the file was already at its current location. But the merge got the content from the old directory and location and applied the change to the new location. – Jonathan Daigle Aug 07 '20 at 17:42

1 Answers1

0

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.

LeGEC
  • 46,477
  • 5
  • 57
  • 104