Counter-intuitive results for git show and git checkout during rebase with conflict.

The scenario: We have two branches, local and master, we are now on
branch local, and we would like to rebase local wrt master:

	% git rebase master
	conflictedfile: needs merge
	cannot rebase: you have unstaged changes

Obviously we have a conflict, here's the problem: these commands have
counter-intuitive effect (as oppose to during a git merge with
conflict):

  git show :2:conflictedfile  # shows content from master version
  git show :3:conflictedfile  # shows content from local version

  git checkout --ours conflictedfile   # gets content from master version
  git checkout --theirs conflictedfile # gets content from local version

I know why they are counter-intuitive - :2:, :3:, --ours and --theirs
are relative to the current <commit>, and during a conflict due to a
rebase, the current <commit> is some commit that leads to master,
which is not anywhere in the path that leads to local.

So in summary:

Fact 1:
  During a conflict due to a rebase, HEAD is a commit that leads to
  the other branch.

Fact 2:
  During a conflict due to a merge, HEAD is a commit that leads to the
  current branch.

(Please correct me if the two facts above are not true)

Technically there's nothing wrong with the behavior of the commands,
but wouldn't it be better if the arguments :2:conflictedfile and
:3:conflictedfile to git show and the options --ours and --theirs to
git checkout be made aware of the two facts above and do a more
intuitive action?

Or should this be left to a higher level tools to automatically detect
the reason of the conflict and adjust the arguments appropriately so
that the end results are intuitive for the user?

nazri.

On Sun, Feb 22, 2009 at 11:04 PM, Nazri Ramliy [off-list ref] wrote:

The scenario: We have two branches, local and master, we are now on
branch local, and we would like to rebase local wrt master:

       % git rebase master
       conflictedfile: needs merge
       cannot rebase: you have unstaged changes

Obviously we have a conflict, here's the problem: these commands have
counter-intuitive effect (as oppose to during a git merge with
conflict):

 git show :2:conflictedfile  # shows content from master version
 git show :3:conflictedfile  # shows content from local version

 git checkout --ours conflictedfile   # gets content from master version
 git checkout --theirs conflictedfile # gets content from local version

I know why they are counter-intuitive - :2:, :3:, --ours and --theirs
are relative to the current <commit>, and during a conflict due to a
rebase, the current <commit> is some commit that leads to master,
which is not anywhere in the path that leads to local.

So in summary:

Fact 1:
 During a conflict due to a rebase, HEAD is a commit that leads to
 the other branch.

Fact 2:
 During a conflict due to a merge, HEAD is a commit that leads to the
 current branch.

(Please correct me if the two facts above are not true)

Technically there's nothing wrong with the behavior of the commands,
but wouldn't it be better if the arguments :2:conflictedfile and
:3:conflictedfile to git show and the options --ours and --theirs to
git checkout be made aware of the two facts above and do a more
intuitive action?

Or should this be left to a higher level tools to automatically detect
the reason of the conflict and adjust the arguments appropriately so
that the end results are intuitive for the user?

I took a crack at fixing this issue in the UI (well, just mergetool),
but that wasn't the right way to do it. See Junio's reply in this
thread:

http://thread.gmane.org/gmane.comp.version-control.git/74595

So, patches welcomed. :-)

j.