{"thread":{"id":"17961","subject":"Counter-intuitive results for git show and git checkout during rebase with conflict.","startedAt":"2009-02-23T04:04:53Z","lastAt":"2009-02-23T07:16:41Z","messageCount":2,"participants":["Nazri Ramliy","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"105839","messageId":"544dda350902222004v742a7175od19ac417f75ddd1a@mail.gmail.com","threadId":"17961","inReplyTo":null,"subject":"Counter-intuitive results for git show and git checkout during rebase with conflict.","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2009-02-23T04:04:53Z","receivedAt":"2009-02-23T04:04:53Z","isPatch":false,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"The scenario: We have two branches, local and master, we are now on\nbranch local, and we would like to rebase local wrt master:\n\n\t% git rebase master\n\tconflictedfile: needs merge\n\tcannot rebase: you have unstaged changes\n\nObviously we have a conflict, here's the problem: these commands have\ncounter-intuitive effect (as oppose to during a git merge with\nconflict):\n\n  git show :2:conflictedfile  # shows content from master version\n  git show :3:conflictedfile  # shows content from local version\n\n  git checkout --ours conflictedfile   # gets content from master version\n  git checkout --theirs conflictedfile # gets content from local version\n\nI know why they are counter-intuitive - :2:, :3:, --ours and --theirs\nare relative to the current <commit>, and during a conflict due to a\nrebase, the current <commit> is some commit that leads to master,\nwhich is not anywhere in the path that leads to local.\n\nSo in summary:\n\nFact 1:\n  During a conflict due to a rebase, HEAD is a commit that leads to\n  the other branch.\n\nFact 2:\n  During a conflict due to a merge, HEAD is a commit that leads to the\n  current branch.\n\n(Please correct me if the two facts above are not true)\n\nTechnically there's nothing wrong with the behavior of the commands,\nbut wouldn't it be better if the arguments :2:conflictedfile and\n:3:conflictedfile to git show and the options --ours and --theirs to\ngit checkout be made aware of the two facts above and do a more\nintuitive action?\n\nOr should this be left to a higher level tools to automatically detect\nthe reason of the conflict and adjust the arguments appropriately so\nthat the end results are intuitive for the user?\n\nnazri.\n"},{"id":"105875","messageId":"76718490902222316m768d202fib4671d7782b47de@mail.gmail.com","threadId":"17961","inReplyTo":"544dda350902222004v742a7175od19ac417f75ddd1a@mail.gmail.com","subject":"Re: Counter-intuitive results for git show and git checkout during rebase with conflict.","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-23T07:16:41Z","receivedAt":"2009-02-23T07:16:41Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Feb 22, 2009 at 11:04 PM, Nazri Ramliy <ayiehere@gmail.com> wrote:\n> The scenario: We have two branches, local and master, we are now on\n> branch local, and we would like to rebase local wrt master:\n>\n>        % git rebase master\n>        conflictedfile: needs merge\n>        cannot rebase: you have unstaged changes\n>\n> Obviously we have a conflict, here's the problem: these commands have\n> counter-intuitive effect (as oppose to during a git merge with\n> conflict):\n>\n>  git show :2:conflictedfile  # shows content from master version\n>  git show :3:conflictedfile  # shows content from local version\n>\n>  git checkout --ours conflictedfile   # gets content from master version\n>  git checkout --theirs conflictedfile # gets content from local version\n>\n> I know why they are counter-intuitive - :2:, :3:, --ours and --theirs\n> are relative to the current <commit>, and during a conflict due to a\n> rebase, the current <commit> is some commit that leads to master,\n> which is not anywhere in the path that leads to local.\n>\n> So in summary:\n>\n> Fact 1:\n>  During a conflict due to a rebase, HEAD is a commit that leads to\n>  the other branch.\n>\n> Fact 2:\n>  During a conflict due to a merge, HEAD is a commit that leads to the\n>  current branch.\n>\n> (Please correct me if the two facts above are not true)\n>\n> Technically there's nothing wrong with the behavior of the commands,\n> but wouldn't it be better if the arguments :2:conflictedfile and\n> :3:conflictedfile to git show and the options --ours and --theirs to\n> git checkout be made aware of the two facts above and do a more\n> intuitive action?\n>\n> Or should this be left to a higher level tools to automatically detect\n> the reason of the conflict and adjust the arguments appropriately so\n> that the end results are intuitive for the user?\n\nI took a crack at fixing this issue in the UI (well, just mergetool),\nbut that wasn't the right way to do it. See Junio's reply in this\nthread:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/74595\n\nSo, patches welcomed. :-)\n\nj.\n"}]}