Re: git stash apply usability issues

From: Karl Hasselström <kha@treskal.com>
Date: Oct 19, 2007, 13:27 UTC
Message-ID: <20071019132753.GA23765@diana.vm.bytemark.co.uk>
In-Reply-To: <20071019013156.GU14735@spearce.org>

On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote:

> Johannes Sixt <j.sixt@viscovery.net> wrote:

Show 12 quoted lines

> > (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.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle