Проблема с драйвером Git Merge - PullRequest
Новая
       5

Проблема с драйвером Git Merge

2 голосов
/ 23 июня 2010

Я пытаюсь получить git, чтобы разрешить очень ручное слияние из-за того, как мой код (длинная история, это объяснено здесь ).Я почти получил все, что хотел, просто чего-то не хватает в конкретной ситуации.Не должно быть слишком сложно: у меня есть собственный драйвер для использования WinMerge с чем-то вроде c:/wm/winmerge.exe $1 $2 $3 (в c: /wm/wmrg.sh), git config merge.mnl.driver = "c:/wm/wmrg.sh %B %A %A" и echo *.xml merge=mnl > $GIT_DIR/info/attirbutes.

Теперь, когда я git merge dev, он открывает WinMerge, и позвольте мне сделать работу - блестяще.Он просто не работал в следующей ситуации:

Передача двух моих ветвей ( master и dev ) с некоторыми изменениями, ожидающими в dev длябыть объединенным в производство.

  1. Вернуться к master
  2. Переименовать некоторые файлы, не связанные с изменениями (скажем, некоторые readme.txt в manual.txt) в devи передайте его
  3. Перейдите к dev и объедините эти изменения с master [, когда новый драйвер включится и спросит вас, должен ли он передать эти конфиги другим файлам в dev.Вы выходите из WinMerge без сохранения, поэтому не переносите информацию.После того, как вы закончите просматривать XML, txt не фильтруется и переименовывается в dev ]
  4. , теперь обратно в master, объединение dev

Здесь я ожидаю, что драйвер снова включится и будет вести себя так же, как XML.По какой-то причине, хотя, когда вы пытаетесь git merge dev, он решает все слить автоматически!

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

пожалуйста, сообщите ..

спасибо

Ответы [ 2 ]

1 голос
/ 23 июня 2010

Я думаю, я понял это .. То, что я имею здесь, на самом деле является концептуальной проблемой. Это не может быть сделано в Git, по крайней мере, не так, как я хотел.

Все эти усилия были направлены на то, чтобы по завершении цикла разработки у меня были dev и master ветви на одном уровне фиксации. Теоретически, отличается только парой строк, которые специфичны для их среды, но, тем не менее, весь остальной код одинаков.

Если я правильно понял, каждый коммит в git идентифицируется как SHA-1 из этой версии, поэтому, если какой-либо файл отличается на один символ, это не может быть тот же коммит.

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

Как я уже прокомментировал, мне удалось применить определенные изменения назад и вперед, используя cherry-pick, но единственный реальный способ правильно отслеживать master и dev - использовать ключевое слово фильтры расширения (как описано VonC здесь и здесь и многие другие там)

Спасибо за помощь,

е.

1 голос
/ 23 июня 2010

Git может посчитать, что:

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

И поскольку драйвер слияния запускается только для общих файлов, это не происходит в случае второго слияния.

...