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 черной магии уступить второй этап в этом индексе и третий этап в рабочем репо... но я не знаю, как это сделать, поэтому я делаю это вручную.: - (

3 ответа

Я задал вопрос в списке рассылки git. Я описываю ожидаемое поведение. Это не ошибка.: - (

Вот ответ, который я получил:

Если вы не отредактировали ручку вручную, каждый кусок будет либо в state HEAD или в состоянии A, и применяя разницу между HEAD и A до такой файл будет либо no-op (hunk уже применен), либо успешное приложение.

Для меня это серьезное ограничение git add --patch, и я не понимаю, каким образом это поведение может быть полезным для всех, но я научусь жить с ним.


Чтобы создать и протестировать индекс, содержащий часть рабочего дерева, в том числе отредактированные вручную, выполните следующие действия:

git add --patch <files>
git stash --keep-index
<test the="" indexed="" changes="">
git reset --hard
git stash pop --index
</test></files>

В этот момент конфликтов нет, а репозиторий, индекс и рабочий каталог находятся в состоянии, непосредственно предшествующем git stash. Теперь вы можете git commit проиндексировать изменения.

Конечно, это довольно странно и не очень интуитивно, и мне бы очень хотелось узнать, есть ли более простой способ сделать это.


git stash --keep-index сохраняет ваш индекс, но он все еще добавляет содержимое индекса как часть кошелька.

Попробуйте git stash save -p - немного более утомительно, чтобы сохранить кошелек, но, вероятно, сделает то, что вы хотите.

licensed under cc by-sa 3.0 with attribution.