gitgitksource-control-explorer

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

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?

Solution

  • 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 the 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.

    Another difference, the support of pathspec magic: Before Git 2.42 (Q3 2023), "git [-c log.follow=true] log [--follow] ':(glob)f**'" used to barf.

    See commit 8260bc5, commit 9eac595, commit 8e32caa (01 Jun 2023) by Jeff King (peff).
    (Merged by Junio C Hamano -- gitster -- in commit de00f4b, 20 Jun 2023)

    diff: detect pathspec magic not supported by --follow

    Reported-by: Jim Pryor
    Signed-off-by: Jeff King

    The --follow code doesn't handle most forms of pathspec magic.
    We check that no unexpected ones have made it to try_to_follow_renames() with a runtime GUARD_PATHSPEC() check, which gives behavior like this:

    $ git log --follow ':(icase)makefile' >/dev/null
BUG: tree-diff.c:596: unsupported magic 10
Aborted

    The same is true of ":(glob)", ":(attr)", and so on.
    It's good that we notice the problem rather than continuing and producing a wrong answer.
    But there are two non-ideal things:

    1. The idea of GUARD_PATHSPEC() is to catch programming errors where low-level code gets unexpected pathspecs.
      We'd usually try to catch unsupported pathspecs by passing a magic_mask to parse_pathspec(), which would give the user a much better message like:

      pathspec magic not supported by this command: 'icase'

      That doesn't happen here because git-log usually does support all types of pathspec magic, and so it passes "0" for the mask (this call actually happens in setup_revisions()). It needs to distinguish the normal case from the "--follow" one but currently doesn't.

    2. In addition to --follow, we have the log.follow config option.
      When that is set, we try to turn on --follow mode only when there is a single pathspec (since --follow doesn't handle anything else).
      But really, that ought to be expanded to "use --follow when the pathspec supports it".
      Otherwise, we'd complain any time you use an exotic pathspec:

      $ git config log.follow true
$ git log ':(icase)makefile' >/dev/null
BUG: tree-diff.c:596: unsupported magic 10
Aborted

      We should instead just avoid enabling follow mode if it's not supported by this particular invocation.

    This patch expands our diff_check_follow_pathspec() function to cover pathspec magic, solving both problems.