очистка бухгалтерского учета эквивалентных изменений по веткам в git

Question

Я пытаюсь очистить большое количество веток тем, в первую очередь, чтобы в обзоре ветвей для master в github больше не отображались ложные индикаторы «n вперед» в неактивных ветках тем из-за наличия идентичных изменений.

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

На приведенной ниже диаграмме Y - это коммит в ветви topic, который позже был применен к master как Y' (поэтому у них разные хэши sha1, но идентичные идентификаторы патчей).

A --- B --- C --- Y' --- E    <-- master
       \ 
        X --- Y               <-- topic

git cherry master topic соответственно сообщает:

- Y

Но если я попытаюсь исправить это, выдав git merge topic из master, я получу конфликт слияния, поскольку изменение E в master с тех пор изменило контекст, к которому применено исправление.

Есть ли способ сказать master "Эй, у вас действительно есть Y, так что вы можете перестать сообщать, что у вас его нет"? (Возможность сделать это таким образом, чтобы его можно было применять автоматически / программно, является ключевым фактором.)

Answer 1

Вы можете увидеть эффективную разницу в ревизиях между ветвями, передав опцию --cherry-pick в git log.

Мои любимые заклинания:

git log --left-right --graph --cherry-pick --oneline branch1...branch2

(которые у меня есть псевдонимы как git lr).

Из страницы руководства :

--cherry-pick 

Пропустить любой коммит, который вводитто же самое изменение, что и другой коммит на «другой стороне», когда набор коммитов ограничен симметричной разностью .

Например, если у вас есть две ветви, A и B, обычный способ перечисления всех коммитов только на одной их стороне - с помощью --left-right (см. Пример ниже в описании --left-rightопция).Однако он показывает коммиты, которые были выбраны вишней из другой ветви (например, «3-е на b» может быть выбрано вишней из ветви A). При использовании этой опции такие пары коммитов исключаются из вывода .

--cherry-mark 

Как --cherry-pick (см. ниже выше )но помечайте эквивалентные коммиты с = вместо их пропуска, а неэквивалентные с +.

---

Постоянное решение # 1

Чтобы навсегда перестать беспокоиться о коммитах, которые были фактически выбраны, вы всегда можете объединить другой филиал.Коммит слияния будет помечен как дочерняя ревизия как предыдущего коммита , так и кончика слитого дерева ревизий .

Это говорит об обходе дерева ревизий, чтобы прекратить просмотр истории в этой точке.Это было бы безопасно только при объединении ревизии из «другой» ветки IFF, вы ** знаете, что все ее родители были объединены (насколько вы захотите, чтобы они были объединены).

Постоянное решение # 2

Существует также способ использования графтов .Это действительно ничего не значит, кроме того, что вы скажете git - out of band 1 - что определенная ревизия является дочерней по отношению к другой ревизии, без необходимости фактически переходить на / слияния с ней.

_{1 как, рукописный файл с парами хэшей sha1:)}

Положительным моментом является то, что вы не иметь переписать историю , чтобы это работало.Однако, если вы хотите, вы можете использовать git filter-branch, чтобы сделать трансплантаты постоянными .Вам больше не нужен файл grafts , но, конечно, вы вернетесь с недостатками необходимости переписывать историю (и, возможно, аннулировать опубликованные идентификаторы ревизий).

Свободные концы?

Если все остальное терпит неудачу, иногда вы можете застревать с удаленными (тематическими) ветками, из которых вы часто хотите объединяться, но есть различия, которые вы просто никогда не захотитебрать.Это, вероятно, приведет к одним и тем же конфликтам слияния снова и снова.

В этом случае я просто укажу на git-rerere (повторное использование записанного разрешения конфликтующих слияний) , которое может значительно облегчить жизнь, хотя и сложнее

Answer 2

Я не уверен, почему я не думал об этом раньше, но пока идентичный список изменений - единственное отличие между master и topic, git merge -s ours topic от master, легко решит проблему , Слияние, очевидно, будет применяться без конфликтов, а наличие слияния устранит ложный необработанный индикатор.

Моя страница обзора ветки github теперь не содержит вводящих в заблуждение индикаторов «впереди», так что подлинные неотправленные коммиты будут четко выделяться.

Answer 3

Это своего рода странный шаг вокруг нежелания rebase истории, поскольку это публичное репо, но рассмотрим решение с revert, merge и счетчиком revert.

* 1006.* На master, верните E и Y 'отдельно, чтобы восстановить master до его состояния в C (с сообщениями о фиксации, сообщающими, что вы вносите в ветку забытой темы, а не удаляете изменения):

git revert E
git revert Y'

Запишите вниз sha1 коммита возврата для E или git tag revert_E sha1 it.

Теперь вы сможете объединить свой topic с master:

git merge topic

стема правильно слилась в этот момент, и master вернулось в свое состояние вплоть до Y / Y ', теперь вы можете revert свой возвратный коммит E для его восстановления:

git revert revert_E

, который будет применяться корректнопоскольку master находится в том же состоянии, в котором он находился, когда вы изначально фиксировали E (история этого состояния только что изменилась).Чувствуется немного акробатично, но решит вашу проблему.Я не могу придумать ничего более чистого.