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
