Re: git stash apply usability issues
- From
David Kastrup <dak@gnu.org>
- Date
- Oct 19, 2007, 13:57 UTC
- Message-ID
- <86y7dz9ph8.fsf@lola.quinscape.zz>
- In-Reply-To
- <20071019132753.GA23765@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
Show 23 quoted lines
> On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote:
>
>> Johannes Sixt <j.sixt@viscovery.net> 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