Re: How do I resolve conflict after popping stash without adding the file to index?

Dmitry Gutov [off-list ref] writes:

Either will reset already-staged changes from the said file, which is
an irreversible operation.

But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no?  That is, the
failed merge wouldn't have touched the index for the path if it
already had changes there in the first place.

If you want to keep them then you do not have to reset, but your
question is about resolving conflict only in the working tree and
leave the index clean, so I do not think "git reset -- $path" would
not lose anything "irreversibly".

On 04/21/2015 12:11 AM, Junio C Hamano wrote:

But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no?  That is, the
failed merge wouldn't have touched the index for the path if it
already had changes there in the first place.

I'm not really sure what "higher stage entries" are, but this scenario 
seems to be a counter-example:

git init
echo "aaaaa" > test
git add test
git commit -m "first"
echo "aaa" > test
git stash save
echo "bbbbb" > test
git add test
git stash pop

Either that, or 'git stash pop' was a destructive operation, and ate the 
staged changes.

If you want to keep them then you do not have to reset, but your
question is about resolving conflict only in the working tree and
leave the index clean, so I do not think "git reset -- $path" would
not lose anything "irreversibly".

Rather, I'd prefer to leave the index as-is, if it makes sense.

Basically, this is about tool automation, see the context here: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20292

On Tue, Apr 21, 2015 at 01:54:56AM +0300, Dmitry Gutov wrote:

I'm not really sure what "higher stage entries" are, but this scenario seems
to be a counter-example:

git init
echo "aaaaa" > test
git add test
git commit -m "first"
echo "aaa" > test
git stash save
echo "bbbbb" > test
git add test
git stash pop

Either that, or 'git stash pop' was a destructive operation, and ate the
staged changes.

Hmm, interestingly, if you do _not_ stage the changes (i.e., drop the
final "git add" there), you get:

  $ git stash pop
  error: Your local changes to the following files would be overwritten by merge:
	test
  Please, commit your changes or stash them before you can merge.
  Aborting

which makes sense. Writing conflict markers into the file would leave
you in a situation where it is hard to recover the "bbbbb" content.

But we seem to skip that safety valve when the content has been staged,
which seems questionable to me (technically we are slightly better off
than the protected case because "bbbbb" was written to a git blob
object, so you can recover it.  But it may be difficult to find the
correct blob in the object database).

-Peff

On 04/22/2015 12:29 AM, Jeff King wrote:

Hmm, interestingly, if you do _not_ stage the changes (i.e., drop the
final "git add" there), you get:

   $ git stash pop
   error: Your local changes to the following files would be overwritten by merge:
	test
   Please, commit your changes or stash them before you can merge.
   Aborting

which makes sense. Writing conflict markers into the file would leave
you in a situation where it is hard to recover the "bbbbb" content.

Indeed.

But we seem to skip that safety valve when the content has been staged,
which seems questionable to me (technically we are slightly better off
than the protected case because "bbbbb" was written to a git blob
object, so you can recover it.  But it may be difficult to find the
correct blob in the object database).

Any suggestions how to restore that content in the index 
programmatically? If it's non-trivial to do, maybe that is indeed a bug, 
and 'git stash pop' should abort before creating the conflict.

On Wed, Apr 22, 2015 at 01:35:05AM +0300, Dmitry Gutov wrote:

quoted

But we seem to skip that safety valve when the content has been staged,
which seems questionable to me (technically we are slightly better off
than the protected case because "bbbbb" was written to a git blob
object, so you can recover it.  But it may be difficult to find the
correct blob in the object database).

Any suggestions how to restore that content in the index programmatically?
If it's non-trivial to do, maybe that is indeed a bug, and 'git stash pop'
should abort before creating the conflict.

Right, I am suggesting that latter: that stash should abort if the index
has modified entries. The abort for modified working tree files is done
by git-merge, which can be selective about which entries will be changed
(since it knows which ones need written).  I haven't thought hard enough
to say whether it should be doing the same for the index (i.e., whether
this is a "merge" problem or a "stash" problem).

-Peff