带有作者过滤器的 git diff
我有一系列不同作者的提交,我希望看到两次提交之间的 git dff 输出,但只考虑其中一位作者的提交,例如 git 中的 --author日志。
我对最终的摘要差异感兴趣,而不是各个提交的差异。
有 git 技巧吗?
I have a series of commits by different authors and I would like to see a git dff
output between 2 commits but only considering the commits by one of the authors, something like, something like --author in git log.
I am interested in the final summary diff and not the diffs of the individual commits.
Is there a git trick for that?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
也许您可以使用 diff 的格式化功能-树
然后您可以 grep 查找相关作者。
May be you could use the formatting features of diff-tree
You can then grep on the relevant author.
这里的问题是在一般情况下你不能这样做。假设爱丽丝更改了一个特定文件,然后鲍勃更改了它 - 包括爱丽丝更改的部分 - 最后爱丽丝再次更改了它。如何将 Alice 的两个差异合并为一个差异?如果您将它们视为两个补丁,那么如果不先应用 Bob 的补丁,第二个补丁就不会应用!但您也不能简单地将最终状态与原始状态进行比较,因为这将包括 Bob 的更改。
如果您更喜欢 git 操作的示例,这就像进行交互式变基,并且只是删除随机提交。当然,有时它会起作用,但有时它会完全失败,因为其中一项提交依赖于您删除的提交之一。
所以,我知道你说过你不想要单独的提交差异,但这就是你真正希望的:
或者如果你真的非常渴望单个差异,这将为你提供它,但只有在存在的情况下没有像我上面提到的那样的补丁交互:
这确实需要在工作树中进行操作,因为一旦跳过提交,绝对不能保证任何补丁都会应用。你只需要尝试看看。
The problem here is that you can't do this in the general case. Suppose Alice changes a particular file, then Bob changes it - including parts that Alice changed - and finally Alice changes it again. How do you combine Alice's two diffs into a single diff? If you take them as two patches, the second simply won't apply without Bob's patch being applied first! But you also can't simply diff the final state against the original, because that will include Bob's changes.
If you prefer an example with git operations, this is like doing an interactive rebase, and just deleting random commits. Sure, sometimes it'll work, but sometimes it'll just completely fail, because one of those commits depended on one of the ones you took out.
So, I know you said you don't want individual commit diffs, but that's all you can really hope for:
Or if you're really desperate for a single diff, this will get it for you, but only in the cases where there's no patch interaction like I mentioned above:
This does really require operations in the work tree, because there's absolutely no guarantee that any of the patches will apply once a commit has been skipped. You just have to try and see.