相当于git log的gitk - 关注<文件的完整路径> [英] gitk equivalent of git log --follow <full path to file>

查看:299
本文介绍了相当于git log的gitk - 关注<文件的完整路径>的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我有一个叫做one.txt的文件,我在master分支上多年来一直在修改。 gitk one.txt将显示该特定文件的整个历史记录。然而,在我更改one.txt => two.txt后,gitk two.txt在重命名之前不显示任何更改。



我试过gitk - 关注两个。 txt,但只给每个提交注释,但不是实际的文件更改信息。



我知道我可以做git log - follow two.txt,但是你必须将每个SHA1值分别填写到每个正在更改的内容中。



那么,有什么提示? 解决方案

问题在于 gitk --follow 现在与 git log --follow 有所不同,考虑到 - follow code>主要是一个黑客:


我很确定我在提到原始跟踪补丁时提到了这个问题,它基本上归结为: - 遵循是一个完全的破解,而不是使用常规的提交过滤功能,并且作为结果,花哨诸如 - 父母之类的东西实际上并不适用。



IOW,我不是完全可以肯定它是可以修复的。 - 关注是一件非常基础的事情,而且确实是一个彻头彻尾的黑客。这是一个相当小的破解 - 如果你并没有更好地了解源代码,你可能会认为它非常适合git,但不会。



现在,我们可能会破解 - 父母也可以使用 - 跟着,但坦率地说,我不知道如何。 - follow hack基本上可以归结为:


  • do 不是 prune完全提交(这是通常简化父母身份并删除无趣提交的东西)


    • git log ,使用寻找重命名的魔法特殊破解工具进行补丁生成。


  • 如果它是重命名的,请更改我们魔法跟踪的路径,以便我们看下一个提交,我们将遵循新(较旧)的路径。

  • 如果补丁为空,我们强制隐藏提交(内部,这是 rev-> always_show_header = 0; thing)



这里的关键是我们在 end 完成所有魔术在我们完成修改通常是父母身份重命名的提交之后很久,排队。



对不起。我偶尔使用了 - 遵循,但是看到确定,它重命名了是个黑客攻击。如果 gitk --follow< pathname> 正常工作,但它不是我关心的内容。



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?

解决方案

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.

这篇关于相当于git log的gitk - 关注&lt;文件的完整路径&gt;的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆