# git stash and manually edited chunks 6 messages from 2010-11-01 to 2010-11-03. Participants: Olivier Verdier, Matthieu Moy, Gavin Guo. Thread: https://gitlist.dev/t/25606 ## Olivier Verdier, 2010-11-01 07:27 Subject: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/AANLkTik6esqP2EkA6SFmfS0zdokG1iTKXqivA2wnpq%3D9%40mail.gmail.com ``` 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, 2010-11-01 16:58 Subject: Re: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/vpqfwvlkmkv.fsf%40bauges.imag.fr In-Reply-To: ``` Olivier Verdier 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/ ``` ## Olivier Verdier, 2010-11-02 08:37 Subject: Re: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/AANLkTiknhRGuBMFEKbVdyN83SiF9j2nNz%3Dv-nMaD-iTb%40mail.gmail.com In-Reply-To: ``` 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 wrote: > Olivier Verdier 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, 2010-11-02 09:02 Subject: Re: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/vpqd3qoxfma.fsf%40bauges.imag.fr In-Reply-To: ``` Olivier Verdier 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, 2010-11-03 03:06 Subject: Re: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/AANLkTi%3DO8oPjcPN1j8513Kp%2BOtY7Cs5WgdiVhHnyzX%3DC%40mail.gmail.com In-Reply-To: ``` > 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, 2010-11-03 10:53 Subject: Re: git stash and manually edited chunks Message-ID: URL: https://gitlist.dev/e/vpqr5f2ptjb.fsf%40bauges.imag.fr In-Reply-To: ``` Gavin Guo 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/ ```