Rugged (libgit2) этап для индекса

Question

Глядя на индекс (после вызова merge_commits между ведущим и филиала), я вижу 3 результаты для того же файла,

{:path=>"file.txt", :oid=>"c6fdbacd7400805042668f4ccf70fc1ebbdac361", :dev=>0, :ino=>0, :mode=>33188, :gid=>0, :uid=>0, :file_size=>0, :valid=>false, :stage=>1, :ctime=>1969-12-31 19:00:00 -0500, :mtime=>1969-12-31 19:00:00 -0500} 
{:path=>"file.txt", :oid=>"0838a4be16d19278e1e549614ffd2b6759549185", :dev=>0, :ino=>0, :mode=>33188, :gid=>0, :uid=>0, :file_size=>0, :valid=>false, :stage=>2, :ctime=>1969-12-31 19:00:00 -0500, :mtime=>1969-12-31 19:00:00 -0500} 
{:path=>"file.txt", :oid=>"4bd2639f786bef1000dad7d59c6779a4e99fb27c", :dev=>0, :ino=>0, :mode=>33188, :gid=>0, :uid=>0, :file_size=>0, :valid=>false, :stage=>3, :ctime=>1969-12-31 19:00:00 -0500, :mtime=>1969-12-31 19:00:00 -0500} 

Мое понимание, глядя на содержание каждого из них состоит в том, что этап 3 является самым «последним/продвинутым» изменением, но может ли кто-нибудь объяснить концепцию этих этапов и нумерацию? И этап 0 отсутствует, потому что есть изменения в этом файле, которые не являются постоянными?

Answer 1

Я не знаком с libgit2, но ненулевые этапы в индексных файлах git предназначены для решения конфликтов слияния.

До тех пор пока конфликт не будет разрешен, будет до трех записей для одного имени пути, как описано в the gitrevisions documentation:

двоеточие, необязательно с последующим числом стадии (от 0 до 3) и двоеточие, за которым следует путь, называет объект blob в индексе по данному пути. Недопустимый номер этапа (и двоеточие, который следует за ним), обозначает запись этапа 0. Во время слияния этап 1 является общим предком, второй этап - версией целевой ветви (как правило, текущей ветвью), а этап 3 - это версия из ветки, которая объединяется.

Если слияние конфликт происходит из-за удалением (то есть файл существует в общем предке, но отсутствует в одной отрасли и модифицирован в других), будет только один из стадии 2 или 3; если это из-за создания (файл не существовал в общем предке, но был создан в обеих ветвях), не будет записи в 1-й стадии. (Я не уверен, что здесь были охвачены все случаи, когда осталось менее 3 записей.)

Прежде чем вы сможете закончить и зафиксировать слияние, вы должны заменить ненулевые записи в кадре на одну ступень-0.

Answer 2

Когда вы выполняете слияние, git нуждается в изменениях на каждом конце базовой версии. Индекс записывает идентификатор базовой версии и каждую версию подсказки oid, как 1 (базовая) 2 («наша»), 3 («их»). Запись идентификатора содержимого позволяет повторно запускать различия в разных параметрах (например, для получения отчетов о конфликтах с тремя конфликтами или для игнорирования изменений в пробелах) по мере необходимости. Этап 0 для разрешенного содержимого, контент без слияния в потоке.