谁删除了我在 git 中的更改?

发布于 2024-12-02 21:13:27 字数 586 浏览 1 评论 0原文

这是我过去 30 分钟遇到的问题:我的一个文件中的一些更改消失了,而且我不知道是什么时候发生的。我想知道是谁干的!

我开始寻找包含我的文件的修订:

git grep <searched_string> $(git rev-list --all) -- <file>

是文件的路径或像 *.gsp 这样的通配符

我有一堆修订,我查看最后一个,并尝试获取它的子项(认为第一个子项应该是我的更改消失的第一个修订版)

git rev-list --children <revision_id>

是距上一个命令最后一行开头的 40 个字符

Getting close!我正在查看输出的开头,并获取第一个子项,然后运行

git log <revision_id_s_first_child> --stat

然后我查看输出并找到我的文件以及谁进行了更改! (事实证明,我是罪魁祸首......)

有没有办法做得更快(gitblame不会显示已删除的内容)?

Here was my problem for the last 30 minutes: I had a couple of changes that disappeared in one of my files, and I don't know when that happened. And I want to know who did that!

I started looking for the revisions having my files:

git grep <searched_string> $(git rev-list --all) -- <file>

is the path to the file or a wildcard like *.gsp

I got a bunch of revisions, I look at the last one, and try to get it's children (thinking the first child should be the first revision where my changes disappeared)

git rev-list --children <revision_id>

is the 40 chars from the beginning of the last line of the previous command

Getting close! I am looking at the beginning of the output, and take the first child and then run

git log <revision_id_s_first_child> --stat

Then I look at the output and find my file and who did the change!
(it turned out, I was to blame...)

Is there anyway to do that faster (git blame would not show what has been deleted) ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

堇年纸鸢 2024-12-09 21:13:27

git Blame 有一个 --reverse 选项,它接受一系列提交,并显示行被删除之前存在的最后一次提交。因此,您找到一个您知道这些行在那里的提交,例如 abcdef01,并显示删除之前的最后一次提交,请执行以下操作:

git blame --reverse abcdef01..HEAD -- <file>

git blame has a --reverse option that takes a range of commits and shows you the last commit where a line existed before it was deleted. So, you find a commit you know the lines were there, let's say abcdef01 for example, and to show the last commit before the delete, do:

git blame --reverse abcdef01..HEAD -- <file>
偏闹i 2024-12-09 21:13:27

如果您知道被删除的行中的某些子字符串,则可以使用 -G 选项来 git log 来查找引入了添加或更改的更改的提交删除包含该子字符串的行。例如,如果您知道单词“pandemic”在消失的行中,您可以执行以下操作:(

git log -Gpandemic -p

-G 的参数可以是正则表达式。)此选项是最近添加到 git 中的 -如果它不起作用,请尝试使用 -S ,它的语义略有不同,但应该具有类似的效果。

If you know some substring that would be in the line that was removed, then you can use the -G option to git log to find commits that introduced a change that added or removed lines containing that substring. e.g. if you knew that the word "pandemic" was in the line that disappeared, you can do:

git log -Gpandemic -p

(The parameter to -G can be a regular expression.) This option was added rather recently to git - if it doesn't work, try -S instead, which has slightly different semantics, but should have a similar effect.

初见你 2024-12-09 21:13:27

请注意,自 Git 2.11(2016 年第 4 季度)开始,如果您想查看特定提交和当前提交之间的提交,则不必指定 ..HEAD

所以Karl Bielefeldt答案将是:

 git blame --reverse abcdef01 -- <file>

参见提交 d993ce1(2016 年 6 月 14 日),作者:Junio C Hamano (gitster
(由 Junio C Hamano -- gitster -- 合并于 提交 1172e16,2016 年 10 月 10 日)

blame:dwim“blame --reverse OLD”为“blame --reverse OLD..

说“gitblame --reverse OLD path”是一个常见的错误,期望命令行被隐藏,就好像询问旧版本 OLD 中的路径中的行如何存活到当前提交。

我们可以将 DWIM“OLD”(这可能是拼写错误的“OLD..”)作为一个范围,而不是总是要求范围的两端在当前提交处结束。

git Blame --reverse现在包括:

--reverse <rev>..<rev>:

让历史向前走,而不是向后走。
这不会显示其中出现一行的修订,而是显示其中存在一行的最后一个修订。
这需要一系列修改,例如 START..END,其中责任路径存在于 START 中。
为了方便起见,git Blame --reverse START 被视为 git Blame --reverse START..HEAD

(注:“dwim”是“Do What I Mean”的缩写(不是我说的))

Note that since Git 2.11 (Q4 2016), you won't have to specify ..HEAD if you want to look at commits between a specific one and the current one.

So Karl Bielefeldt's answer would then be:

 git blame --reverse abcdef01 -- <file>

See commit d993ce1 (14 Jun 2016) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 1172e16, 10 Oct 2016)

blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."

It is a common mistake to say "git blame --reverse OLD path", expecting that the command line is dwimmed as if asking how lines in path in an old revision OLD have survived up to the current commit.

Instead of always requiring both ends of a range, we could DWIM "OLD", which could be a misspelt "OLD..", to be a range that ends at the current commit.

git blame --reverse now include:

--reverse <rev>..<rev>:

Walk history forward instead of backward.
Instead of showing the revision in which a line appeared, this shows the last revision in which a line has existed.
This requires a range of revision like START..END where the path to blame exists in START.
git blame --reverse START is taken as git blame --reverse START..HEAD for convenience.

(Note of the note: "dwim" is an acronym for "Do What I Mean" (not what I say))

花间憩 2024-12-09 21:13:27

git Blame --reverse 可以让您接近删除该行的位置。但它实际上并不指向该行被删除的修订版。。它指向该行存在最后修订版本。然后,如果以下修订版普通提交,那么您很幸运,并且获得了删除修订版。 OTOH,如果以下修订是合并提交,那么事情可能会变得有点疯狂。作为创建 difflame 工作的一部分,我解决了这个问题,所以如果你已经在你的盒子上安装了 python 并且你愿意尝试一下,那么不要再等了,让我来知道事情进展如何。

https://github.com/eantoranz/difflame

git blame --reverse can get you close to where the line is deleted. But it actually doesn't point to the revision where the line is deleted. It points to the last revision where the line was present. Then if the following revision is a plain commit, you are lucky and you got the deleting revision. OTOH, if the following revision is a merge commit, then things can get a little wild. As part of the effort to create difflame I tackled this very problem so if you already have python installed on your box and you are willing to give it a try, then don't wait any longer and let me know how it goes.

https://github.com/eantoranz/difflame

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文