Git stash и отредактированные куски
Я полностью люблю git add -p
и git stash
, но у меня иногда возникает следующая проблема, которая воспроизводится с помощью следующей последовательности команд:
-
git add -p my_file
: тогда я отредактирую ручку вручную (используя e
), потому что расщепление, которое предлагает git, мне не подходит
-
git stash --keep-index
: тогда я делаю некоторое тестирование, и если тесты проходят, я не совершаю
-
git stash pop
: теперь возникает проблема: файл my_file
теперь считается конфликтующим, а git полностью перепутал мой отредактированный hunk, поэтому мне нужно отредактировать файл, удалите бесполезные метки слияния и запустите git add my_file
, а затем git reset HEAD
Я озадачен, потому что это происходит только при редактировании вручную. Я не вижу, как это должно иметь значение вообще.
Чтобы воспроизвести проблему:
-
touch newfile
-
git add newfile
-
git commit -m 'newfile'
- добавить две строки в файл
-
git add -p newfile
- отредактируйте hunk (
e
), удалите одну из строки в hunk, затем закройте git add (q
)
-
git stash --keep-index
-
git stash pop
Теперь файл newfile
находится в незагруженном состоянии. Заметим еще раз, что проблема возникает только с отредактированными вручную файлами. Нет проблем с приведенными выше командами, если вы не вручную отредактируете ручку.
Кстати, предыдущее состояние файла находится на третьем этапе (git show :3:newfile
), а предыдущая поэтапная версия находится на втором этапе (git show :2:newfile
). Таким образом, я мог бы с помощью некоторой git черной магии уступить второй этап в этом индексе и третий этап в рабочем репо... но я не знаю, как это сделать, поэтому я делаю это вручную.: - (
Ответы
Ответ 1
Я задал вопрос в списке рассылки git. Я описываю ожидаемое поведение. Это не ошибка.: - (
Вот ответ, который я получил:
Если вы не отредактировали ручку вручную, каждый кусок будет либо в state HEAD или в состоянии A, и применяя разницу между HEAD и A до такой файл будет либо no-op (hunk уже применен), либо успешное приложение.
Для меня это серьезное ограничение git add --patch
, и я не понимаю, каким образом это поведение может быть полезным для всех, но я научусь жить с ним.
Ответ 2
Чтобы создать и протестировать индекс, содержащий часть рабочего дерева, в том числе отредактированные вручную, выполните следующие действия:
git add --patch <files>
git stash --keep-index
<test the indexed changes>
git reset --hard
git stash pop --index
В этот момент конфликтов нет, а репозиторий, индекс и рабочий каталог находятся в состоянии, непосредственно предшествующем git stash
. Теперь вы можете git commit
проиндексировать изменения.
Конечно, это довольно странно и не очень интуитивно, и мне бы очень хотелось узнать, есть ли более простой способ сделать это.
Ответ 3
git stash --keep-index
сохраняет ваш индекс, но он все еще добавляет содержимое индекса как часть кошелька.
Попробуйте git stash save -p
- немного более утомительно, чтобы сохранить кошелек, но, вероятно, сделает то, что вы хотите.