Hi,
I regularly experience that beginners have problems unterstanding that
--ours and --theirs are swapped when a conflict occurrs on git stash
apply or stash pop.
From the HCI perspective this is really counter intuitive.
So, I'd like to propose that on git shash pop/apply theirs and ours
should be swapped in git index, so that git checkout --theirs and --ours
work as expected.
PS: I'm sorry if this was already discussed, I haven't found any discussion.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
On Sun, Oct 23, 2016 at 12:58:12AM +0200, Sven Strickroth wrote:
I regularly experience that beginners have problems unterstanding that
--ours and --theirs are swapped when a conflict occurrs on git stash
apply or stash pop.
From the HCI perspective this is really counter intuitive.
I know that people have complained about "rebase" swapping the two, but
I don't think anybody has ever mentioned it for stash. I'm not sure I
that they are swapped, though.
The "ours" content is generally what was in the HEAD before the
operation started, and "theirs" is what the operation is bringing into
that history. That is true of "merge" and "cherry-pick". And AFAICT, it
is true of "stash", too (I basically think of "stash apply" as a
cherry-pick).
So with a setup like:
git init
echo base >file
git add file
git commit -m file
echo stash >file
git stash
echo master >file
git commit -am master
git checkout -b branch HEAD^
echo branch >file
git commit -am branch
if we merge, then --theirs is the branch we are merging:
git checkout master
git merge branch
git checkout --theirs file
cat file
# "branch"
Likewise, if we cherry-pick:
git reset --hard
git cherry-pick branch
git checkout --theirs file
cat file
# "branch"
And likewise if we apply the stash:
git reset --hard
git stash apply
git checkout --theirs file
cat file
# "stash"
So that seems consistent to me.
I guess if you are stashing in order to pull somebody else's work, like:
git stash
git pull
git stash pop
then conceptually the stash is "ours" and HEAD is "theirs". This is
exactly like the rebase case. E.g., if you instead did:
git commit -m 'tmp stash'
git pull --rebase
So I sympathize, but I don't think that having "stash" flip the order
would be the right thing to do in all cases. In theory there could be
some kind of option (and things like pull autostash could use it), but I
suspect it may be hard to implement in practice. The unpack-trees code
does not treat "ours" and "theirs" entirely symmetrically (the "ours"
side represents the current working tree, so we might do things like
check whether the index is fresh). I guess you could flip the "1" and
"2" bits in the index after the conflicted merge completes.
I'm still not convinced it's a good idea, though.
-Peff