Git прививка опасна?

Question

Я использовал Git в качестве толстого клиента для репозитория Subversion, и это было здорово. Я должен следовать методологии «один коммит на Trac-билет», но я предпочитаю иметь богатую историю атомарных коммитов для моей собственной выгоды, поэтому у меня появилась следующая привычка:

1. Создать ветку темы для билета Trac
2. взломать, сделать несколько коммитов
3. Используйте git rebase -i на отключенном HEAD, чтобы объединить всю работу в один коммит (сохраняя ветку темы без изменений)
4. Используйте git svn dcommit для фиксации в SVN
5. Объединить элемент обратно с master, затем объединить с trunk до master (этот второй шаг обычно не используется, так как ствол и ветвь объекта должны совпадать)

Это прекрасно синхронизирует master и trunk, сохраняя всю историю, которую я хочу. Единственная проблема в том, что Git считает, что master всегда намного опережает trunk, поскольку, насколько он знает, я ни разу не зафиксировал ни ветку темы, ни master назад к trunk - шаг # 3 проигрывает Происхождение изменений, так что все, что видит Git, - это trunk, напевающее само по себе и master сливающееся как из него, так и из веток темы:

Switched to branch 'master'
Your branch and 'trunk' have diverged,
and have 232 and 1 different commit(s) each, respectively.

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

И, о чудо, есть .git/info/grafts, который, кажется, делает именно то, что я хочу. Я могу даже объединить trunk в master как ускоренное слияние , что морально обычно так и есть. Но, несмотря на то, что результаты могут быть, они кажутся грязными, тем более что это может быть совершенно необязательно.

Так что я хочу знать, есть ли что-нибудь опасное в этой идее? Если, скажем, у меня появляется привычка делать прививку каждый раз, когда я танцую rebase / dcommit, я прошу о проблеме? Должен ли я просто покончить с собой? : -)

Answer 1

Старый вопрос, я знаю, но:

Я думаю, что поддержание разницы между «стволом» и «хозяином» делает вашу жизнь сложнее, чем необходимо. Обычно «master» должен указывать на вершину дерева svn или на быстрые исправления, которые вы собираетесь сделать. Когда вы собрали серию изменений и dcommit, они, тем не менее, я думаю, что следующий логический шаг - настроить прививку так, чтобы dcommited изменения были дочерними по отношению к svn parent и ветке темы, которую вы использовали написать код для билета. Другими словами, изменение, которое вы приняли, становится, с точки зрения git, слиянием дерева svn и вашей ветки тем - что во многих отношениях является тем, чем оно является. Нет нужды создавать добросовестное слияние git для ветки темы.

Answer 2

Я предлагаю вам отказаться от svn, так как вы единственный, кто использует его, и настаиваете на использовании git, но, предположим, вы не можете этого сделать по какой-либо причине, тогда я предлагаю вам прекратить борьбу со своими инструментами и просто использовать git-svnв обычном смысле.

Подумайте о том, чтобы отбросить свою локальную историю в пользу "отточенной" истории, которую вы отправляете в svn.Ваша локальная история отражает вашу собственную работу, то есть ту работу, которую вы еще не готовы показать миру - некоторые тестовые случаи могут быть неудачными или стиль кода может быть уродливым и т. Д. Выполните локальный коммит, отшлифуйте его, протестируйте егоИ затем поместите его в небольшой коммит, который будет загружен на сервер SVN.

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