Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-29 Thread Junio C Hamano
Jeff King writes: > Yeah, I think I agree. But keep in mind that we have to mention the > conflicts _somewhere_, so we're going to touch the index regardless (and > the user is going to have to erase the conflicts in the index > eventually, either with `git add` or `git reset`).

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-29 Thread Alan Mackenzie
Hello, Jeff. On Tue, Dec 29, 2015 at 02:53:30AM -0500, Jeff King wrote: > On Thu, Dec 24, 2015 at 09:20:38AM +, Alan Mackenzie wrote: > > > It seems to be a side effect of merge-recursive to stage the results, > > > and in the no-conflict path we explicitly reset the index. For the > > >

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-29 Thread Jeff King
On Tue, Dec 29, 2015 at 09:20:38PM +, Alan Mackenzie wrote: > > Yeah, I think I agree. But keep in mind that we have to mention the > > conflicts _somewhere_, so we're going to touch the index regardless (and > > the user is going to have to erase the conflicts in the index > > eventually,

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-29 Thread Jeff King
On Tue, Dec 29, 2015 at 11:04:20AM -0800, Junio C Hamano wrote: > [...] > In the above, I suggested to "git reset" when there is no conflict. > I think this line of thinking can be followed even further to > selectively reset the paths that were cleanly merged (which is added > by the call to

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-28 Thread Jeff King
On Thu, Dec 24, 2015 at 09:20:38AM +, Alan Mackenzie wrote: > > It seems to be a side effect of merge-recursive to stage the results, > > and in the no-conflict path we explicitly reset the index. For the > > conflicting case, it's trickier, because we would want to retain the > > unmerged

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-24 Thread Alan Mackenzie
Hello, Jeff. On Tue, Dec 22, 2015 at 04:30:33AM -0500, Jeff King wrote: > On Tue, Dec 22, 2015 at 09:17:38AM +0100, Dennis Kaarsemaker wrote: > > On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote: > > > Hello, git project. > > > Last night, whilst clearing out a stale "stash stack", I did

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-22 Thread Dennis Kaarsemaker
On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote: > Hello, git project. > > Last night, whilst clearing out a stale "stash stack", I did "git stash > pop". There were conflicts in two files. > > However, all the popped files became staged. This doesn't normally happen. > It was intensely

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-22 Thread Jeff King
On Tue, Dec 22, 2015 at 09:17:38AM +0100, Dennis Kaarsemaker wrote: > On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote: > > Hello, git project. > > > > Last night, whilst clearing out a stale "stash stack", I did "git stash > > pop". There were conflicts in two files. > > > > However,

Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-21 Thread Alan Mackenzie
Alan Mackenzie wrote: on Mon, 21 Dec 2015 14:29:54 > Hello, git project. > Last night, whilst clearing out a stale "stash stack", I did "git stash > pop". There were conflicts in two files. > However, all the popped files became staged. This doesn't normally happen. > It was

"git stash pop" is doing an unwanted "git add" when there are conflicts.

2015-12-21 Thread Alan Mackenzie
Hello, git project. Last night, whilst clearing out a stale "stash stack", I did "git stash pop". There were conflicts in two files. However, all the popped files became staged. This doesn't normally happen. It was intensely irritating, and required me to do "git reset HEAD" on each of the