git stash and manually edited chunks

git stash and manually edited chunks

[Olivier Verdier]

Hi!
I asked a question on stackoverflow
(http://stackoverflow.com/questions/4058372/git-stash-and-edited-chunks)
and someone suggested it might be a bug...
For convenience, I reproduce the question here:

 I occasionally have the following problem, which is reproduced by the
following sequence of commands:

* git add -p my_file
* I edit a chunk *manually* (using e)
* git stash --keep-index
* git stash pop

Now the problem occurs: the file my_file is now considered as
conflicted, and git has completely messed with my edited chunk, so I
have to edit the file, remove the merge marks, and run git add my_file
followed by git reset HEAD

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

I'm using version 1.7.3.1 on Mac OS X.

Thanks!!

Re: git stash and manually edited chunks

[Matthieu Moy]

Olivier Verdier <zelbier@gmail.com> writes:

> Hi!
> I asked a question on stackoverflow
> (http://stackoverflow.com/questions/4058372/git-stash-and-edited-chunks)
> and someone suggested it might be a bug...
> For convenience, I reproduce the question here:
>
>  I occasionally have the following problem, which is reproduced by the
> following sequence of commands:

Let's say the state of your working tree here is A (and last commit is
HEAD).

> * git add -p my_file
> * I edit a chunk *manually* (using e)

Here, the index contains a state which is neither in the working tree
nor in the last commit. Let's call this state B.

> * git stash --keep-index

Here, the working tree takes state B.

> * git stash pop

Here, you're trying to apply the stash, which is somehow a diff
between HEAD and A, on your tree which is in state B. Hence the
conflicts.


If you do a "git reset --hard" before the "git stash pop", you'll come
back to state HEAD, and the stash will apply without conflict.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git stash and manually edited chunks

[Olivier Verdier]

Thank you,

but that does not explain why there is a conflict *only* when I edit
the chunk manually, does it?

Besides, some people tried to reproduce my problem on Linux and they
got no conflict after edited chunks.

So it seems that it could be a bug specific to Mac OS X.

== Olivier

On 1 November 2010 17:58, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Olivier Verdier <zelbier@gmail.com> writes:
>
>> Hi!
>> I asked a question on stackoverflow
>> (http://stackoverflow.com/questions/4058372/git-stash-and-edited-chunks)
>> and someone suggested it might be a bug...
>> For convenience, I reproduce the question here:
>>
>>  I occasionally have the following problem, which is reproduced by the
>> following sequence of commands:
>
> Let's say the state of your working tree here is A (and last commit is
> HEAD).
>
>> * git add -p my_file
>> * I edit a chunk *manually* (using e)
>
> Here, the index contains a state which is neither in the working tree
> nor in the last commit. Let's call this state B.
>
>> * git stash --keep-index
>
> Here, the working tree takes state B.
>
>> * git stash pop
>
> Here, you're trying to apply the stash, which is somehow a diff
> between HEAD and A, on your tree which is in state B. Hence the
> conflicts.
>
>
> If you do a "git reset --hard" before the "git stash pop", you'll come
> back to state HEAD, and the stash will apply without conflict.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

Re: git stash and manually edited chunks

[Matthieu Moy]

Olivier Verdier <zelbier@gmail.com> writes:

> Thank you,
>
> but that does not explain why there is a conflict *only* when I edit
> the chunk manually, does it?

It does.

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.

> Besides, some people tried to reproduce my problem on Linux and they
> got no conflict after edited chunks.

I did, on Linux. I get the same behavior as you.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git stash and manually edited chunks

[Gavin Guo]

> Let's say the state of your working tree here is A (and last commit is
> HEAD).
>
>> * git add -p my_file
>> * I edit a chunk *manually* (using e)
>
> Here, the index contains a state which is neither in the working tree
> nor in the last commit. Let's call this state B.
>
>> * git stash --keep-index
>
> Here, the working tree takes state B.
>
>> * git stash pop
>
> Here, you're trying to apply the stash, which is somehow a diff
> between HEAD and A, on your tree which is in state B. Hence the
> conflicts.

I am confusing about the description here. Git stash --keep-index
exist after editing the hunk, so why stash will save the difference
between HEAD and A, I think it should be the state which is modified
by git add -p(using e), and as a result of no conflict.

Gavin Guo

Re: git stash and manually edited chunks

[Matthieu Moy]

Gavin Guo <tuffkidtt@gmail.com> writes:

>> Let's say the state of your working tree here is A (and last commit is
>> HEAD).
>>
>>> * git add -p my_file
>>> * I edit a chunk *manually* (using e)
>>
>> Here, the index contains a state which is neither in the working tree
>> nor in the last commit. Let's call this state B.
>>
>>> * git stash --keep-index
>>
>> Here, the working tree takes state B.
>>
>>> * git stash pop
>>
>> Here, you're trying to apply the stash, which is somehow a diff
>> between HEAD and A, on your tree which is in state B. Hence the
>> conflicts.
>
> I am confusing about the description here. Git stash --keep-index
> exist after editing the hunk, so why stash will save the difference
> between HEAD and A, I think it should be the state which is modified
> by git add -p(using e), and as a result of no conflict.

It's actually both. And indeed, "diff" is slightly oversimplified :
stash saves the state of HEAD and of the index, as two commits. Try
running "gitk --all" after stash to see what's going on.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/