views:

80

answers:

2

I totally love git add -p and git stash but I occasionally have the following problem, which is reproduced by the following sequence of commands:

  • git add -p my_file: then I edit a hunk manually (using e) because the splitting that git suggests does not suit me
  • git stash --keep-index: then I do some testing, and if the tests pass I do not commit
  • git stash pop: now the problem occurs: the file my_file is now considered as conflicted, and git has completely messed with my edited hunk, so I have to edit the file, remove the useless merge marks, and run git add my_file followed by git reset HEAD

I'm puzzled because this happens only when editing a hunk manually. I don't see how this should make any difference at all.


To reproduce the problem:

  • touch newfile
  • git add newfile
  • git commit -m 'newfile'
  • add two lines in the file
  • git add -p newfile
  • edit the hunk (e), remove one of the line in the hunk, then quit git add (q)
  • git stash --keep-index
  • git stash pop

Now the file newfile is in unmerged state. Note, again, that the problem only occurs with manually edited hunks. There is no problem whatsoever with the commands above if one does not edit any hunk manually.

Incidentally, the preceding state of the file is in the third stage (git show :3:newfile), and the previously staged version is in the second stage (git show :2:newfile). So I could, by some git black magic, manage to put the second stage in this index, and the third stage in the working repo... but I don't know how to do that so I do it by hand. :-(

+2  A: 

git stash --keep-index preserves your index, but it still adds the index contents as part of the stash.

Try git stash save -p -- a bit more tedious to save the stash, but will probably do what you want.

bstpierre
How does that explain that git considers that there is a conflict **only** when I have a manually edited chunk?
Olivier