跨git commit调试可执行文件 [英] Debugging executables across git commits
问题描述
有人用git提供了一个调试不同代码版本之间的可执行文件的好方法吗？基本上，我希望能够在最近的一组提交和一组较旧的提交之间生成并行可执行文件，并跟踪相关的代码，以免在提交之间跳转时所有内容被覆盖。
Has anyone come up with a good solution for debugging executables between different code versions using git? Basically, I want to be able to generate side-by-side executables between my recent set of commits and an older set of commits, as well as keep track of the relevant code to go with it, without everything overwriting when jumping between the commits.
当前，我的方法是制作/编译当前代码，并重命名可执行文件以及我要在调试器中尝试分析的任何代码（在我的情况下为gdb） 。现在，对于旧代码，我想在签出较旧的提交之前签出新的分支，因为我很偏执，并且它构建了reflog以获得额外的安全性和检查点（我知道这不是很必要）。我签出旧代码，并在旧提交上运行make文件。现在，我有了可以与gdb一起运行的并行可执行文件。不过，这有点乏味，特别是如果一些头文件/文件已更改（我想破坏我的代码），并且现在我想进行更改并重新编译（我有大量的引用/包含，我基本上只是必须重新开始该过程）。有人有更好的方法吗？
Currently my method of doing this is to make/compile the current code and rename the executable and whatever code I'm trying to analyze in debugger (gdb in my case). Now, to the old code, I like to checkout a new branch before checking out the older commit because I'm paranoid and it builds the reflog for extra safety and check-pointing (I know it's not really necessary). I checkout old code and run the make file on the older commit. Now I have my side-by-side executables that I can run with gdb. It's all a bit tedious though, especially if a few headers/files have changed (I like to break up my code) and also if I now want to make changes and recompile (I've got tons of references/includes and I basically just have to start the process over again). Anyone have a better method?
推荐答案
我最近在尝试调试/升级需要正确使用的库时遇到了类似的问题安装在系统上（使用 make install ），并在最新的稳定版和开发版之间进行跳转。
I recently had a similar problem when trying to debug/upgrade a library which needed to be properly installed on the system (using make install) and make jumps between last stable and development versions.
从2.6.0版开始（大约三年）从现在开始），您现在可以使用
Since version 2.6.0 (about three years from now), you now can use
git worktree
基本上，您可以将自己在任何地方的任何目录都转换为官方git本地存储库的附件。它通过在其顶层填充 .git 文本文件（而不是常规子目录）来完成，其中包含指向原始文本的信息。在存储库方面，此附件被声明为这样，并创建了一个新分支。
It basicaly enables yourself to turn any directory, at any place, into an annex of an official git local repository. It does by filling a .git textfile (instead of the regular subdirectory) at its top level, containing informations that point the original one. On the repository side, this annex is declared as so and a new branch is created.
因此，您现在可以执行 git checkout 同时添加到两个不同的修订版（每个工作目录一个）。您可以根据需要添加任意数量的附件。完成后，只需删除所有无用的附件，然后调用 git worktree prune 使其消除所有不再存在的内容（您可以使用 git worktree lock ，以防止某些附件在附件目录有时不可用时被删除，例如可移动设备）。这样，您就可以同时编译同一应用程序的两个不同版本。
Consequently, you now have the possibility to perform git checkout onto two different revisions simultaneously (one per working directory). And you may add as many annexes as you need. When you're done, simply delete all useless annexes, then call git worktree prune to make it dismiss everything that no longer exists (you may use git worktree lock to prevent some of them to be deleted if their annex directory is to be unavailable sometimes, with removable devices for instance). This will let you compile two different versions of the same application at the same time.
但是，如果您需要检索软件的特定版本，但是可以t在编译之前先告诉哪个，您可能要使用
If, however, you need to retrieve a particular revision of your soft but you can't tell which one before you have compiled it, you may want to use
git bisect run
…相反，它将自动调用一个脚本，该脚本指示修订的好坏。当编译时间较长且整个搜索可能需要几天的时间时，此功能很有用。
…instead, which will automatically call a script that tells if a revision is good or bad. It's useful when a compilation is rather long and when the whole search can span over several days.
Here's a link to the documentation page related to git worktree.
这篇关于跨git commit调试可执行文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
