Отладка исполняемых файлов через git commits

Question

Отладка исполняемых файлов через git commits

1

Кто-нибудь придумал хорошее решение для отладки исполняемых файлов между разными версиями кода с помощью git? В принципе, я хочу иметь возможность создавать побочные исполняемые файлы между моим недавним набором коммитов и более старым набором коммитов, а также отслеживать соответствующий код, чтобы идти с ним, без всякой перезаписи при переходе между коммитами,

В настоящее время мой метод заключается в том, чтобы сделать/скомпилировать текущий код и переименовать исполняемый файл и любой код, который я пытаюсь проанализировать в отладчике (gdb в моем случае). Теперь, в старый код, мне нравится проверять новую ветку, прежде чем проверять старшую фиксацию, потому что я параноик, и он создает рефлог для дополнительной безопасности и проверки (я знаю, что это действительно не обязательно). Я проверяю старый код и запускаю файл make на старшей фиксации. Теперь у меня есть мои бок о бок исполняемые файлы, которые я могу запустить с помощью gdb. Все это немного утомительно, особенно если несколько заголовков/файлов были изменены (мне нравится разбивать мой код), а также если я сейчас хочу внести изменения и перекомпилировать (у меня есть множество ссылок/включает, и я в основном просто должны снова начать процесс). У кого-нибудь есть лучший метод?

Andrew H 18 май 2018, в 01:13

Источник

0

У меня есть две или три копии большинства или репозитории, с которыми я работаю ежедневно.
Retired Ninja 17 май 2018, в 22:58
0

Кажется, что несколько рабочих деревьев все еще находятся в стадии разработки, поэтому я думаю, что если у вас много состояний, то, как вы говорите, вам просто нужно запустить несколько репо. Дисковое пространство дешевеет :).
Andrew H 18 май 2018, в 19:34

Теги:

c++

git

debugging

gdb

1 ответ

Ещё вопросы

У меня есть две или три копии большинства или репозитории, с которыми я работаю ежедневно.
Кажется, что несколько рабочих деревьев все еще находятся в стадии разработки, поэтому я думаю, что если у вас много состояний, то, как вы говорите, вам просто нужно запустить несколько репо. Дисковое пространство дешевеет :).

Obsidian · Accepted Answer · 2018-05-17T20-55-00.000Z

У меня недавно возникла аналогичная проблема при попытке отладки/обновления библиотеки, которая должна была быть правильно установлена в системе (с использованием make install) и совершения переходов между последними стабильными версиями и версиями разработки.

Начиная с версии 2.6.0 (примерно через три года), теперь вы можете использовать

git worktree

Это позволяет вам превратить любой каталог в любом месте в приложение официального git-локального репозитория. Это делается путем заполнения текстового файла .git (вместо обычного подкаталога) на его верхнем уровне, содержащего информацию, указывающую исходную. На стороне хранилища это приложение объявляется так и создается новая ветка.

Следовательно, теперь у вас есть возможность выполнять git checkout на две разные версии одновременно (по одному на рабочий каталог). И вы можете добавить столько приложений, сколько вам нужно. Когда вы закончите, просто удалите все бесполезные приложения, затем вызовите git worktree prune чтобы он отклонил все, что больше не существует (вы можете использовать git worktree lock чтобы некоторые из них не удалялись, если их приложение-каталог иногда недоступно, со съемными устройствами, например). Это позволит одновременно скомпилировать две разные версии одного приложения.

Если, однако, вам нужно получить конкретную ревизию вашего программного обеспечения, но вы не можете определить, какой из них перед его компиляцией, вы можете захотеть использовать

git bisect run

... вместо этого, который автоматически вызовет скрипт, который сообщает, хороша или плохая ревизия. Это полезно, когда компиляция довольно длинная и когда весь поиск может охватывать несколько дней.

Здесь ссылка на страницу документации, относящуюся к git worktree.

Хорошо, это выглядит так, как мне нужно! Я должен дать ему попробовать завтра.