From: David Kastrup Date: Fri, 19 Oct 2007 13:57:23 GMT Subject: Re: git stash apply usability issues Message-ID: <86y7dz9ph8.fsf@lola.quinscape.zz> In-Reply-To: <20071019132753.GA23765@diana.vm.bytemark.co.uk> Karl Hasselström writes: > On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote: > >> Johannes Sixt wrote: > >> > (2) when 'git stash apply' runs merge-recursive, it treats the >> > current state as 'ours' and the stash as 'theirs'. IMHO it should >> > be the other way round: I have stashed away changes to a binary >> > file. Then committed a different modification to it, and now want >> > to apply the stash. This results in a conflict that leaves the >> > current state in the working tree, but I had preferred that the >> > stashed binary file were in the working tree now. >> > >> > What do other git-stash users think about changing the order? >> >> The current order is the same order that git-rebase uses. I'm not >> saying its correct, just that its the same as rebase. > > FWIW, StGit push works the same way. The idea being that the current > HEAD is our current state ("ours"), and the patch we're pushing is > some change we want to apply ("theirs"). I always felt that this was a > very natural order of things. But I guess the philosophy in the > "stash" case is subtly different, so maybe the change is warranted > there. Well, maybe one should then just name this "current" and "separate" instead of "ours" and "theirs". -- David Kastrup