Как git определяет неслитные пути в конфликтах?

Как git получает список не объединенных путей?

Мое понимание git заключается в том, что при слиянии он включает изменения в файл, а затем добавляет его в index. При возникновении конфликта слияния файл не добавляется в индекс и остается в рабочем дереве с маркерами конфликта. Если я запускаю git status, он показывает мне unmerged paths для конфликтующих файлов.

Как git получает список этих файлов? Если я запущу git add для конфликтующего файла с маркерами, он больше не будет отображаться как конфликтующий, поэтому, возможно, маркеры не являются идентификаторами?


git git-merge-conflict
person Max Koretskyi    schedule 28.02.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Если возникает конфликт слияния, файл не добавляется в индекс и остается в рабочем дереве с маркерами конфликта.

Он находится в индексе: см. git ls-files:

Для неслитного пути вместо записи одной пары режим/SHA-1 индекс записывает до трех таких пар; один из дерева O на этапе 1, A на этапе 2 и B на этапе 3.

git read-tree подробно описывает двухстороннее слияние:

Каждая запись «индекса» имеет два бита состояния «стадии».
Этап 0 — это нормальный, и это единственный, который вы увидите при обычном использовании.

Однако, когда вы выполняете git read-tree с тремя деревьями, «стадия» начинается с 1.

Это означает, что вы можете сделать

git read-tree -m <tree1> <tree2> <tree3>

и вы получите индекс со всеми <tree1> записями в "stage1", всеми <tree2> записями в "stage2" и всеми <tree3> записями в "stage3".
При выполнении слияния другую ветвь в текущую ветвь, мы используем общее дерево-предок как <tree1>, текущую главу ветви как <tree2> и другую главу ветви как <tree3>.

См. также "Как заставить git думать, что файл не объединен?".

person VonC    schedule 28.02.2015
comment
Я читаю git read tree и кажется, что слияние выполняется внутри, и только затем обновляются индекс и рабочее дерево, а не наоборот (слияние в рабочем каталоге -> обновление индекса). Это правильно? - person Max Koretskyi; 28.02.2015
comment
@Maximus нет, он использует индекс для выполнения слияния, поэтому он откажется запускаться, если в вашем файле индекса есть неслитые записи, что указывает на то, что вы не завершили предыдущее слияние, которое вы начали. - person VonC; 28.02.2015
comment
Хм, он использует рабочий каталог также для выполнения слияния? Или он обновляет рабочий каталог из индекса, когда слияние выполняется в индексе? Я, наверное, не совсем понимаю, что вы имеете в виду под it uses the index to perform the merge. - person Max Koretskyi; 28.02.2015
comment
@ Максимус Я понимаю, что ты имеешь в виду. См. git-scm.com/docs/git-merge#_true_merge: это будет использовать рабочее дерево как место хранения результата слияния, объединяя HEAD и MERGE_HEAD, и, для конфликтного пути, записывая в индексный файл до трех версий: этап 1 хранит версию от общего предка, этап 2 из HEAD, а этап 3 из MERGE_HEAD (вы можете проверить этапы с помощью git ls-files -u). Файлы рабочего дерева содержат результат программы слияния. Так что да, рабочее дерево и индекс обновляются в соответствии с результатом слияния. - person VonC; 28.02.2015
comment
Понял, спасибо! Я собираюсь прочитать больше о read-tree, так как это кажется лучшим описанием того, что происходит при слиянии. Лучший! - person Max Koretskyi; 28.02.2015
comment
Просто прочитайте read-tree страницу... так что кажется, что git status под unmerged paths показывает пути, для которых не установлен stage 0 бит, верно? - person Max Koretskyi; 28.02.2015
comment
@Maximus Я не видел этого на странице дерева чтения. Я только видел, что команда git write-tree отказывается записывать бессмысленное дерево и будет жаловаться на неслитые записи, если увидит единственную запись, которая не является стадией 0. - person VonC; 01.03.2015
comment
Да, в документации об этом конкретно не говорится, это мое предположение. - person Max Koretskyi; 01.03.2015
comment
не могли бы вы взглянуть на это и это мои вопросы, когда у вас есть время. Заранее спасибо! - person Max Koretskyi; 25.03.2015