On Thu, May 11, 2017 at 02:35:49AM -0400, Jeff King wrote: > > > After doing a subtree merge, using 'git log' and 'git log --follow' on > > > files in the subtree show only the merge commit in which they were > > > added. > > > > > > After reading around I understand that the issue is that git log > > > --follow doesn't track renames that occur during a merge. > > > > Try git log --follow -M. (You may also want to combine this with -l and/or -C). > > You shouldn't need to specify "-M" with --follow, as the diff done by > try_to_follow_renames() turns on rename (and copy) detection explicitly. > I suspect the problem is that git-log does not do merge diffs at all by > default, and you'd need "-c" or "--cc" (or maybe even "-m") to turn them > on. > > I wouldn't be surprised if there are other problems where that code path > isn't quite ready to handle merge commits, though. Hmm. It does seem to work out of the box in a simple example: git init repo cd repo seq 100 >one git add one git commit -m base echo foo >unrelated git add unrelated git commit -m unrelated git checkout -b side HEAD^ git mv one two git commit -m rename git checkout master git merge --no-edit side git log --oneline --raw --follow two And it does not seem to need any special diff options like "-c" to trigger it. It may be that more complex cases fool it (perhaps history simplification has an effect, or perhaps it's the old issue that --follow has a single global idea of the "current" filename, even though it may be traversing down multiple lines of history). Jonny, is it possible for you to share the repo that shows the problem? If not, it might be possible to demonstrate the problem with "fast-export --anonymize", though I think that won't work if the rename is accompanied by a change in the same commit (because it anonymizes away the relationship between two almost-identical files). -Peff