Git перебазировать конфликт с нечего слить? - PullRequest
Новая
       57

Git перебазировать конфликт с нечего слить?

7 голосов
/ 27 октября 2011

Что это значит, когда git rebase обнаруживает конфликт, но в файле нет явной проблемы?В рассматриваемом файле нет маркеров конфликта, и git mergetool говорит «нечего объединять».

У меня есть следующие варианты: сброс или добавление : 

# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      filename.js

Как мне узнать, о чем идет речь, и какой путь выбрать?

git ls-files -s filename.js дает 3 строки: 

100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1   filename.js
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2   filename.js
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3   filename.js

Согласно прекрасному руководству, этоКоманда сообщает нам биты режима, имя объекта и номер этапа.Биты режима одинаковы.Так что же такое 1, 2 и 3, и почему они «оба модифицированы», но не показывают маркеры конфликта?

Ответы [ 2 ]

8 голосов
/ 27 октября 2011

Версии в индексе, помеченном 1, 2 и 3, имеют следующее значение:

  1. Файл, каким он был у общего предка двух коммитов, которые вы объединяете.
  2. Файл, который был в HEAD, т.е. ваш текущий коммит, когда вы сделали слияние.
  3. Файл в коммите, который вы пытаетесь объединить в HEAD.

Мой источник этой информации полезный раздел руководства git по разрешению конфликтов .

Вывод both modified в git status указывает, конечно, что файл был изменен по-разному двумя коммитами, которые вы объединяете с момента их общего предка.

Для меня довольно загадочно, почему вы не видите маркеры конфликта в файле, однако - что у BLOB-объектов есть разные имена объектов (хэши) в выводе git ls-files -s, что означает, что побайтные байты они, безусловно, делают имеют разное содержание. Если вы довольны файлом в том виде, в каком он есть в вашей рабочей копии, вы можете просто сделать git add filename.js, а затем git rebase --continue. Тем не менее, в любом случае вы можете узнать, в чем заключались эти различия. Для этого я бы попробовал следующее: 

git diff :2:filename.js filename.js

... который покажет различия между версией в HEAD и вашей текущей рабочей копией. Точно так же вы можете попробовать: 

git diff :3:filename.js filename.js

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

1 голос
/ 27 октября 2011

1, 2 и 3 из git ls-files -s представляют собой "стадию" 3-стороннего слияния : 1 является общим предком, 2 является текущая ветка HEAD, а 3 - другая ветка HEAD. В Linux вы можете попробовать следующие команды, чтобы увидеть, что отличается между файлами: 

$ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps
...