threads / discuss / 25606

git stash and manually edited chunks

Subject: git stash and manually edited chunks

## tl;dr

6 messages between Nov 1, 2010 and Nov 3, 2010.

replies: 5people: 3as markdown or json

Olivier Verdier· Nov 1, 2010, 07:27 UTC · lore

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!!

Matthieu Moy· Nov 1, 2010, 16:58 UTC · re: Olivier Verdier · lore

Re: git stash and manually edited chunks

Olivier Verdier <zelbier@gmail.com> writes:

Show 8 quoted lines

> 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/

Olivier Verdier· Nov 2, 2010, 08:37 UTC · re: Matthieu Moy · lore

Re: git stash and manually edited chunks

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:

Show 38 quoted lines

> 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/
>

Matthieu Moy· Nov 2, 2010, 09:02 UTC · re: Olivier Verdier · lore

Re: git stash and manually edited chunks

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/

Gavin Guo· Nov 3, 2010, 03:06 UTC · re: Matthieu Moy · lore

Re: git stash and manually edited chunks

Show 18 quoted lines

> 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

Matthieu Moy· Nov 3, 2010, 10:53 UTC · re: Gavin Guo · lore

Re: git stash and manually edited chunks

Gavin Guo <tuffkidtt@gmail.com> writes:

Show 23 quoted lines

>> 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/