git stash and edited hunks

Question

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. :-(

I tried several times, but I cannot reproduce your problem with git version 1.7.2.3. What version are you using? — Sven Marnach, Oct 31 '10 at 15:46
Tried again with different random edits in `git add -p` -- and it always works fine for me. I'm on Linux by the way. Sounds like a bug -- I would recommend asking on the git mailing list, they are quite responsive. — Sven Marnach, Oct 31 '10 at 20:28
According to the mailing list, it is not a bug, it is the expected behaviour. I don't understand why, though... — Olivier Verdier, Nov 03 '10 at 07:51

score 9 · Answer 1 · edited Mar 20 '12 at 17:50

9

To create and test an index containing part of the working tree changes, including manually edited hunks, do:

git add --patch <files>

git stash --keep-index

<test the indexed changes>

git reset --hard

git stash pop --index

At this point there are no conflicts, and the repository, index, and working directory are in the state immediately preceding the git stash. You can now git commit the indexed changes.

Of course, this is rather weird and not very intuitive and I would really like to know whether there is an easier way to do this.

edited Mar 20 '12 at 17:50

Lesmana

25,663
9
82
87

answered Mar 14 '11 at 16:37

frank

481
8
16

1

+1, this works. I've come to the same solution myself but missed the --index switch. This is a logical way of doing things considering it stashes both the index and the unstaged changes so to avoid the merge conflict between the staged changes in the working copy and in the stashed ones one has to first remove those from the working copy (i.e. do a hard reset). – axk Oct 14 '11 at 09:05

score 4 · Accepted Answer · answered Nov 03 '10 at 11:14

4

I asked the question in the git mailing list. What I describe is the expected behaviour. It's not a bug. :-(

Here is the answer I got:

If you did not edit the hunk manually, each hunk will be either in state HEAD or in state A, and applying the diff between HEAD and A to such file will be either a no-op (hunk already applied), or a successfull application.

For me this is a severe limitation of git add --patch, and I don't understand in what way this behaviour may be useful to anyone, but I will learn to live with it.

answered Nov 03 '10 at 11:14

Olivier Verdier

46,998
29
98
90

1

Looks like the problem is that when you do "git stash --keep-index" it stashes both the staged and unstaged changes the only difference being that it preserves the staged changes in the working copy. And when you try to apply the stash the staged changes are both in the working copy and in the stash causing a conflict. In the case of non-edited hunks as they answered it remembers which hunks are present in the working copy and which are not and does not apply the once present avoiding merge conflicts. For an edited hunk only a part of it applied it cannot do the trick. – axk Oct 14 '11 at 08:45

score 2 · Answer 3 · answered Oct 31 '10 at 01:58

2

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.

answered Oct 31 '10 at 01:58

bstpierre

30,042
15
70
103

How does that explain that git considers that there is a conflict **only** when I have a manually edited chunk? – Olivier Verdier Oct 31 '10 at 05:18
Because your indexes are not matching when you git stash pop. – Scott Nov 01 '10 at 02:25
@Scott: sorry, I don't understand your answer... :-/ why is there a conflict only when there was a manually edited chunk? – Olivier Verdier Nov 01 '10 at 07:17
@Olivier - See Sven's comment above: it's worth asking on the git list to see if you've found a bug. – bstpierre Nov 01 '10 at 13:26

git stash and edited hunks

3 Answers3

Linked