2010-05-28 4 views
4

Я использую хэши SHA1 моих коммитов в качестве ссылок в документации и т. Д. Я понял, что если мне нужно будет переписать эти коммиты, мне нужно создать таблицу поиска, чтобы соответствовать хэшам для исходного репо с хэшами для отфильтрованного репо. Так как это эффективные UUID, простая таблица поиска.создание таблицы поиска хеша во время `git filter-branch` или` git-rebase`

Я считаю, что писать сценарий, чтобы сделать это во время прогона filter-branch, довольно просто; на самом деле это не мой вопрос, хотя, если есть какие-то затруднения, которые усложняют ситуацию, я бы очень хотел услышать о них. Я действительно задаюсь вопросом , если есть какие-либо инструменты, которые предоставляют эту функцию, или если есть какое-то соглашение о том, где сохранить таблицу поиска/что называть ее? Я бы предпочел не делать что-то совершенно своеобразным образом.

+0

Я бы не рекомендовал использовать хеши в документации в типичном проекте. Это заставляет вас зависеть от полной истории, а не от одной версии (если вы упаковываете источники, которые вам нужно упаковать с полным репозиторием). Это, конечно, не имеет значения. Мне интересно узнать, можно ли это сделать тоже :) – iwein

+0

Сами ссылки также являются частью репо. Это своего рода длинная история ... на самом деле «документация» - это нечто вроде упрощения. Я держу свои заметки ... ну, почти все .. в git. Ссылка на фиксации полезна, потому что я иногда ссылаюсь на набор заметок из сеанса заметок (например, мои заметки о опции '-pickaxe-regex'' git log'); и б) я иногда на самом деле ссылаюсь на ревизию в некоторых репозиториях исходного кода; и c) Иногда я имею в виду изменение состояния системы (я также использую некоторые из этих материалов в git). Но . , , – intuited

+0

. , , также может быть полезно иметь такую ​​перекрестную ссылку для использования системой отслеживания ошибок/отслеживания ошибок, например, такую, которая хранит данные формы «фиксированные в фиксации $ SHA1». В противном случае, я думаю, вам нужно обновить отслеживатель проблем как часть сценария 'filter-branch'. – intuited

ответ

1

Вы можете хранить исходные хэши в сообщениях фиксации, например git-svn, с изменениями.

Вы также можете использовать git-notes, чтобы комментировать новые коммиты с их исходными хэшами. Примечания хранятся в специальном ref, refs/notes/commits. Это означает, что они будут за пределами истории аннотированной ветви, но это дает вам больше свободы для их изменения.

+0

Я думаю, что хранение хэшей в сообщениях фиксации является наиболее подходящим решением. – intuited

 Смежные вопросы

  • Нет связанных вопросов^_^