问题
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 (usinge
) because the splitting that git suggests does not suit megit stash --keep-index
: then I do some testing, and if the tests pass I do not commitgit stash pop
: now the problem occurs: the filemy_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 rungit add my_file
followed bygit 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. :-(
回答1:
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.
回答2:
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.
回答3:
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.
来源:https://stackoverflow.com/questions/4058372/git-stash-and-edited-hunks