git sparse checkout - невозможно отменить слияние
Использование git 2.25.1 Используется git sparse-checkout init/set для настройки sparsecheckout.
Теперь я в ситуации, когда мне нужно прервать слияние.
Пытался:
git merge --abort
Запись "QStreams_xxx/infra/QPrism/Qpvc/gradle_pvc/gradle_pvc.iml" не обновлена. Невозможно обновить разреженную кассу. фатальный: не удалось сбросить индексный файл до версии "HEAD"
Пытался:
git reset --hard
То же сообщение об ошибке.
Пытался отключить sparse-checkout
git sparse-checkout disable
Ошибка:
ошибка: невозможно отключить разреженную проверку: у вас есть неустановленные изменения. ошибка: кроме того, ваш индекс содержит незафиксированные изменения.
Есть ли выход из этого?
Спасибо, Вооз
2 ответа
Слияние должно быть более надежным в Git 2.34 (4 квартал 2021 г.): различные операции слияния были подготовлены для эффективной работы с разреженным индексом.
Это особенно верно в отношении новой (и используемой по умолчанию) стратегии слияния ORT («Якобы двойник рекурсивного», которая будет использоваться по умолчанию в Git 2.34, четвертый квартал 2021 г.).
См. коммит 516680b, коммит 5d9c934, коммит c0b9930 , коммит 6957636, , коммит ad90da7 (8 сентября 2021 г.) Деррика Столи (
derrickstolee).
(Объединено Junio C Hamano --
gitster-- в коммите a16dd13, 20 сентября 2021 г.)
коммит a338063
merge: сделать разреженным с ORTПодписал: Деррик Столи.
Рецензировал: Элайджа Ньюрен.
Разрешать '
git merge'( man ) для работы без расширения разреженного индекса, по крайней мере, не сразу.
Индекс по-прежнему будет расширен в нескольких случаях:
Если стратегия слияния «рекурсивная», то мы включаем command_requires_full_index в начале метода merge_recursive(). Мы ожидаем, что у пользователей с разреженным индексом также будет включена стратегия 'ort'.
При использовании стратегии 'ort', если слияние приводит к конфликтующему файлу, мы расширяем индекс перед обновлением рабочего дерева. Цикл, проходящий по рабочему дереву, заменяет элементы индекса и отслеживает '
original_cache_nr', что может стать совершенно неверным, если индекс расширится в середине операции. Этот предохранительный клапан важен до запуска этой петли. Более позднее изменение сфокусирует это на расширении только в том случае, если у нас действительно есть конфликт за пределами конуса разреженной проверки.Другие стратегии слияния выполняются как
git merge-X subcommand, и эти стратегии в настоящее время защищены защитой command_requires_full_index.Требуются некоторые тестовые обновления, включая ошибочный '
git checkout -b' ( man ) , в котором не была указана базовая ветвь, в результате чего слияния были быстрыми слияниями.
Не уверен, что это лучший поток, но, по крайней мере, он дает мне выход...
git read-tree --restore HEAD
#now usual cleanup
git restore .
git clean -xdf