Thread (8 messages) flat view 8 messages, 5 authors, 2016-06-15

Re: git stash apply usability issues

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:43:43

On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote:
Johannes Sixt [off-list ref] wrote:
quoted
(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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help