Re: Stash pop/apply conflict and --theirs and --ours

[Jeff King <peff@xxxxxxxx>]

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