【Hacker News搬运】Git作为调试工具

[hackernews]

Title: Git as a debugging tool

Git作为调试工具

Text:

hn link

Url: https://lucasoshiro.github.io/posts-en/2023-02-13-git-debug/

Git可以用作调试工具，除了传统的内存泄漏检测器、分析器和调试器等方法。仓库包含了很多关于代码更改的信息，因此它是调试的一个宝贵资源。从仓库中提取信息的一些有用概念和工具包括路径规范（pathspec）、git ls-files、git grep、git blame、git log和git bisect。这些工具可以帮助查找代码、识别特定行或字符串的引入，并通过在好提交和坏提交之间进行二分查找来定位错误。

文中提供了使用`git bisect`命令在大代码库中查找错误源的步骤。该过程包括启动二分查找、指定一个好提交和一个坏提交，然后运行一个测试脚本来确定当前提交是好是坏。`git bisect run`命令通过使用指定的测试脚本来自动化这个过程。作者最后强调了这些命令在导航大代码库和理解代码方面的实用性。他们还邀请读者在他们的GitHub页面上报告任何错误或建议。

Post by: lucasoshiro

Comments:

teeray: Remember that the more you treat commit history as something to be read, the better these tools get. If you’re just jamming “-m” on git commit with nonsense like “fix bug”, “pr comments”, “ci”, then you’re going to have a bad time debugging with Git. Also, if you have mandatory squash and merge, congrats, you’re destroying history all the time that can help you debug things.

teeray: 请记住，您越是将提交历史记录视为可阅读的内容，这些工具就越好。如果你只是用“修复bug”、“pr comments”、“ci”之类的废话在“git commit”上加上“-m”，那么你在使用git进行调试时会遇到麻烦。此外，如果你有强制性的压缩和合并，恭喜你，你一直在破坏历史，这可以帮助你调试事情。

****:

****:

izoow: I recently found out that git rebase has a --exec option that allows you to execute a shell command for each commit. If the command fails, the rebase pauses and allows you to make changes to make the command pass. I use this to make sure that there is no commit that leaves my project in an unbuildable state.

izoow: 我最近发现git-rebase有一个--exec选项，允许您为每次提交执行一个shell命令。如果命令失败，rebase将暂停并允许您进行更改以使命令通过。我使用它来确保没有使我的项目处于无法构建状态的提交。

ozay: <i>git blame shows only who made the last change. Maybe that person only changed the name of a variable, applied a codestyle change, moved a function declaration to another file or many other things that the change was almost irrelevant to the code behavior.</i><p>There are a few options that help you out with this:<p>-M Detect moved or copied lines within a file<p>-C In addition to -M, detect lines moved or copied from other files that were modified in the same commit.<p>--ignore-rev <rev> Ignore changes made by the revision when assigning blame, as if the change never happened<p>--ignore-revs-file <file> Ignore revisions listed in file<p><a href="https://git-scm.com/docs/git-blame" rel="nofollow">https://git-scm.com/docs/git-blame</a>

ozay: <i> git指责只显示谁做出了最后的改变。也许那个人只是更改了变量的名称，应用了代码样式更改，将函数声明移动到另一个文件，或者其他许多与代码行为几乎无关的事情</i> <p>有几个选项可以帮助您做到这一点：<p>-M检测文件中移动或复制的行<p>-C除了-M之外，还可以检测在同一提交中修改的其他文件中移动和复制的行<p> --忽略rev&lt；rev&gt；在指定责任时忽略修订版所做的更改，就好像更改从未发生过一样<p>--Ignore revs file&lt；文件&gt；忽略文件中列出的修订<p><a href=“https://；&#x2F；git scm.com&#x2F！docs&#x2F：git curson”rel=“nofollow”>https://&#x2F；git scm.com；docs&#x2F；git指责</a>

cerved: Another thing you can do when you have two versions, one which fails and one which doesn't, but where the commits are of the messy work in progress nature and not atomic changes, is gradually stage the changes from the bad version onto the good version until it starts failing<p>Basically git checkout -p until things fail

cerved: 当你有两个版本时，你可以做另一件事，一个失败，另一个不成功；t、 但是，提交是混乱的进行中工作性质的，而不是原子性的更改，是逐渐将更改从坏版本转移到好版本，直到它开始失败<p>基本上是gitcheckout-p，直到事情失败