From: Jay Soffian Date: Mon, 23 Feb 2009 07:16:41 GMT Subject: Re: Counter-intuitive results for git show and git checkout during rebase with conflict. Message-ID: <76718490902222316m768d202fib4671d7782b47de@mail.gmail.com> In-Reply-To: <544dda350902222004v742a7175od19ac417f75ddd1a@mail.gmail.com> On Sun, Feb 22, 2009 at 11:04 PM, Nazri Ramliy 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 , and during a conflict due to a > rebase, the current 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.