gitk equivalent of git log --follow <full path to file>

Question

So I have a file called one.txt that I have been modifying over the years on master branch. gitk one.txt will show the entire history of that one particular file. However after I changed one.txt => two.txt, gitk two.txt doesn't show any change before the rename.

I tried gitk --follow two.txt, but only gave the comment for each commit, but not the actual file change information.

I know I can do git log --follow two.txt, but you have to gitk each SHA1 value to each what is being changed.

So any tips?

Answer 1

The problem is gitk --follow will for now differ from git log --follow, considering, according to Linux Torvalds, --follow is mainly a hack:

I'm pretty sure I mentioned about this exact issue when I posted the original follow patches, and it basically boils down to: "--follow" is a total hack, and does not use the regular commit filtering function, and as a result, fancy things like "--parent" don't really work well with it.

IOW, I'm not at all certain that it is fixable. "--follow is a very fundamentally non-gitty thing to do, and really is a complete hack. It's a fairly small hack - if you didn't know better and looked at the source code, you might think that it fits very naturally into git. But no.

Now, it's possible that we could hack up --parent to work with --follow too, but quite frankly, I don't know how. Because the --follow hack really basically boils down to:

• do not prune commits at all (this the the thing that normally simplifies the parenthood and removes uninteresting commits)
  • for the whole list of normal commits in "git log", do the patch generation with a magic special hack that looks for renames.
• if it was a rename, change the path that we magically track, so that next commit that we look at, we'll follow the new (older) path.
• if the patch is empty, we force-hide the commit (internally, this is the "rev->always_show_header = 0;" thing)

and the key here is that we do all the magic at the end of the queue, long after we've done the pruning of commits that normally does the parenthood renaming.

Sorry. I have used --follow occasionally, but it's a hack to see "ok, there it got renamed". It would be nice if "gitk --follow <pathname>" worked properly, but it's just not something I care very much about.