On Sun, Feb 22, 2009 at 11:04 PM, Nazri Ramliy <ayiehere@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
