37

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?

Lii
  • 9,906
  • 6
  • 53
  • 73
nobody
  • 2,489
  • 4
  • 33
  • 36

1 Answers1

30

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.

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 4
    Sigh...always the git he is. He should care about this >. – nobody Jul 23 '11 at 05:17
  • I suppose there are no updates for this... @qin have you at least tried Git Extensions? Its `--follow` seem to work fine. – cregox Jul 05 '12 at 18:05
  • 1
    @Cawas no evolution that I can see in the logs of git (https://github.com/git/git/tree/master/Documentation/RelNotes). – VonC Jul 05 '12 at 18:14
  • 1
    I'm almost opening a new question, Von... This was so far the closest I got to why `--follow` isn't properly following a file, on `git` (not gitk). Binary file, if that matters. Would you have any pointers on that? :P – cregox Jul 05 '12 at 18:18
  • @Cawas no pointer right now, but consider `--follow` is based on a diff mechanism (http://stackoverflow.com/questions/3520023/how-does-git-track-history-during-a-refactoring/3520055#3520055), which I doubt is working for binaries (using "binary diff": http://stackoverflow.com/a/4705537/6309) . – VonC Jul 05 '12 at 18:21
  • @Cawas: Even the diff stats aren't ideal for binaries: https://bbs.archlinux.org/viewtopic.php?id=141917 – VonC Jul 05 '12 at 18:29
  • I think I've found the google groups with the quote you brought from Linus, also very insightful on the issue: https://groups.google.com/forum/?fromgroups#!topic/git-version-control/07oWjHiQTtg – cregox Jul 05 '12 at 18:43
  • @Cawas sure, it was also from http://thread.gmane.org/gmane.comp.version-control.git/147037/focus=147089 – VonC Jul 05 '12 at 19:18
  • Just wanted to note, in light of the Linus excerpt, that --follow *sometimes* does the right thing, even if not with gitk. In the thread VonC and Cawas found ("Git log follow question") Linus says "'git log --follow' works fine. As does 'git blame -C'." But "git log" does not *always* do what you'd hope either: "fancy things like '--parent' don't really work well with it." – Chris Jun 12 '13 at 19:33
  • This is the primary stopper to refactoring of project structure. The nearest native workaround on gitk is to filter commits using file mask (and storing it as a view), ofc this is useless for commits beyond a simple file move (e.g. abc renamed to xyz) – prusswan Jan 02 '15 at 03:10