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

[Jay Soffian <jaysoffian@gmail.com>]

On Sun, Feb 22, 2009 at 11:04 PM, Nazri Ramliy <ayiehere@gmail.com> 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.