разрешить все измененные ими или удаленные ими во время перебазирования

Я делаю переустановку, где я хотел бы всегда брать конфликтующие файлы как есть из ветви A.

на ветке А

git rebase -X theirs branchQ

(Согласно Есть ли их версия git merge - s наш? и Выберите Git стратегия слияния для определенных файлов (наших, моих, их): «их» должно означать «использовать версии из A». При переустановке их и наши значения меняются местами по отношению к слиянию)

Но у меня все еще возникают конфликты с файлами, которые были изменены и удалены. Я хотел бы постоянно использовать содержимое для А.

git status

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

        deleted by them: A/XB.cs
        deleted by them: A/YB.cs
        deleted by them: B/XD.cs
        deleted by them: B/YD.cs

и многое другое.

Я могу исправить это с помощью git rm A/XB.cs и т. Д., но как я могу принять все эти удаления (и все другие изменения из ветки A)? (Это 28-этапное перебазирование, поэтому я м ищу автоматику)

Что касается общего родителя ветвей A и branchQ, branchQ содержит только нормализацию окончания строки, а не новые или удаленные файлы.


git rebase
person Johan Lundberg    schedule 16.02.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Короткий ответ заключается в том, что -X аргумент вообще не влияет на то, что я называю конфликтами высокого уровня. См. -X их параметр, похоже, не работает с некоторыми конфликтами Git, а также Каковы причины и случаи, которые вызывают конфликты слияния git?

У меня нет готового сценария, который сделает это за вас, но поэкспериментируйте с:

git ls-files --stage

Обратите внимание, что файлы, которые были «удалены ими», будут существовать как записи в промежуточных слотах 1 и 2, но не в слоте 3. Это имена, которые нужно передать git rm, чтобы сообщить Git об удалении записей этапов 1 и 2.

Описание того, как слияние использует четыре промежуточных слота, разрешенных для каждой записи файла в индексе, см. В разделе Как содержимое индекса git изменяется во время слияние (и что в индексе после неудачного слияния)?

person torek    schedule 16.02.2019
comment
Спасибо. Что вы имеете в виду под этапами и слотами? Я понял, что альтернативным подходом было бы заставить filter-branch позвонить git add --renormalize ., но я не уверен, как это сделать. - person Johan Lundberg; 16.02.2019
comment
Ах, мне нужна еще одна ссылка, где я описываю, как слияние работает в индексе с использованием различных промежуточных слотов ... - person torek; 16.02.2019
comment
Может, мне просто не хватило смелости? Сейчас пытаюсь git filter-branch --tree-filter 'git add --renormalize .' parentID..HEAD - person Johan Lundberg; 16.02.2019
comment
Ой, не делай этого, это пустая трата времени. --tree-filter предназначен для изменения дерева на месте: filter-branch извлекает все файлы во временный каталог, вы изменяете файлы на месте, а filter-branch создает новую фиксацию из любых файлов и содержимого. ты оставил позади. add --renormalize вообще не трогает дерево работы! - person torek; 16.02.2019
comment
Вы можете, если хотите, сделать что-нибудь эквивалентное: использовать --tree-filter, чтобы запустить редактор / очиститель для всех извлеченных файлов. Обратите внимание, что $ PWD во время фильтрации дерева указывает на некоторый подкаталог в глубине временного каталога, созданного git filter-branch, не на обычное дерево работы; здесь Git возьмет новые файлы, чтобы сделать новую фиксацию. - person torek; 16.02.2019
comment
:-) Да. Но как мне подражать тому, что делает git add --renormalize ., делая что-то с рабочим деревом? Я мог бы сам начать разбирать файлы и манипулировать ими, но легко ошибиться. Некоторый контекст: я использую autorclf в Windows. Репо содержит ›100000 файлов со смешанными окончаниями строк и набор двоичных файлов с различными именами, отмеченными атрибутами .gitattributes. Возможно, проще написать сценарий, который извлекает содержимое каждой фиксации по очереди в пустой каталог, добавляет с помощью git add --renormalize и фиксирует. Или, возможно, мне стоит пойти с вашим ответом и проверить git ls-files --stage. Большое спасибо! - person Johan Lundberg; 16.02.2019
comment
В общем, если вы не контролируете все клоны репозитория, использование filter-branch в любом случае - плохая идея. Я бы посоветовал поступить иначе, если только это не ваш собственный репозиторий или вы не можете заставить всех остальных переключиться на ваши переписанные коммиты. - person torek; 16.02.2019
comment
Да, это понятно. Речь идет о ветке, для которой еще нет общего доступа. В любом случае я планирую сначала / также сделать одну нормализационную фиксацию, совместно используемую мастером, в согласованное время. Пытаемся сохранить эту работу .... Мы начали перемещаться по каталогам в этой ветке и не осознавали, что это вызывает перенормировку из-за autocrlf ... - person Johan Lundberg; 16.02.2019
comment
Ах, хорошо, тогда это достаточно безопасно. Тем не менее, есть проблема перенормировки. Возможно, есть способ адаптировать трюк, который я описал здесь. - person torek; 16.02.2019

arrow_upward
0
arrow_downward

У меня была такая же проблема, и я нашел в Linux имена файлов без пробелов, которые я могу использовать:

git status --short | grep "^UD"| cut -d " " -f 2|xargs git add

Статус UD определяет файлы, которые не объединены, удалены ими.

person Brent K.    schedule 02.06.2021