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 - немного более утомительно, чтобы сохранить кошелек, но, вероятно, сделает то, что вы хотите.