{"thread":{"id":"23251","subject":"[PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","startedAt":"2010-03-30T15:34:17Z","lastAt":"2010-04-04T06:44:57Z","messageCount":10,"participants":["Jon Seymour","Johannes Sixt"],"isPatch":true,"patchVersion":3,"patchTotal":2},"messages":[{"id":"138183","messageId":"2cfc40321003300834w59532e58m13d42acce4f2c5ce@mail.gmail.com","threadId":"23251","inReplyTo":null,"subject":"[PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-30T15:34:17Z","receivedAt":"2010-03-30T15:34:17Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"This variant of the patch uses git diff -c instead of git diff HEAD,\nat Johannes Sixt's suggestion.\n\nThe diff displayed in case of a merge conflict now shows the\ndifferences between the merge result and each of the local and remote\nheads and thus now also allows the user to assess the consequences of\n\"Use Remote Version\" by showing how the merge result affects the state\nof the local branch.\n\nI have avoided using gmail client to forward this version of  patch\nbecause of documented word-wrapping issues, so hopefully this will\napply cleanly.\n\n[PATCH v3 1/2] git-gui: Introduce is_unmerged global variable to\nencapsulate its derivation.\n[PATCH v3 2/2] git-gui: change to display the combined diff in the\ncase of conflicts.\n\njon.\n"},{"id":"138263","messageId":"4BB2F7A0.6020702@viscovery.net","threadId":"23251","inReplyTo":"2cfc40321003300834w59532e58m13d42acce4f2c5ce@mail.gmail.com","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-31T07:20:00Z","receivedAt":"2010-03-31T07:20:00Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/30/2010 17:34, schrieb Jon Seymour:\n> This variant of the patch uses git diff -c instead of git diff HEAD,\n> at Johannes Sixt's suggestion.\n> \n> The diff displayed in case of a merge conflict now shows the\n> differences between the merge result and each of the local and remote\n> heads and thus now also allows the user to assess the consequences of\n> \"Use Remote Version\" by showing how the merge result affects the state\n> of the local branch.\n> \n> I have avoided using gmail client to forward this version of  patch\n> because of documented word-wrapping issues, so hopefully this will\n> apply cleanly.\n> \n> [PATCH v3 1/2] git-gui: Introduce is_unmerged global variable to\n> encapsulate its derivation.\n> [PATCH v3 2/2] git-gui: change to display the combined diff in the\n> case of conflicts.\n\nI looked at the result, but it does not convince me. In my case, I have a\nlarge file that has many changes between the \"maint\" and \"master\"\nbranches. Whenever there are conflicts after merging \"maint\" to \"master\",\nI see all these changes, and really they *are* uninteresting.\n\nBut I, too, think that to offer \"Use local version\" and \"Use remote\nversion\" is *very* dangerous in a modify/modify conflict, particularly to\nnew-comers. I have only ever found these commands useful in the case of\nmodify/delete conflicts (and they are actually very handy in this case).\n\nEven when the user sees all changes and can make a decision whether \"Use\nlocal\" or \"remote version\" is really wanted, it is not at all obvious\nwhich of the changes shown belong the \"local\" and which to \"remote\".\n\nTherefore, I suggest to keep the original --cc display, but do not offer\n\"Use local version\" and \"Use remote version\" when there is a modify/modify\nconflict. The user is already offered \"Run mergetool\", and it is the safe\noption besides editing the file.\n\n-- Hannes\n"},{"id":"138272","messageId":"k2p2cfc40321003310412hf4c6d642n4349af3f644829ff@mail.gmail.com","threadId":"23251","inReplyTo":"4BB2F7A0.6020702@viscovery.net","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-31T11:12:30Z","receivedAt":"2010-03-31T11:12:30Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> I looked at the result, but it does not convince me. In my case, I have a\n> large file that has many changes between the \"maint\" and \"master\"\n> branches. Whenever there are conflicts after merging \"maint\" to \"master\",\n> I see all these changes, and really they *are* uninteresting.\n>\n\nI think you may have missed the point of my patch.\n\nThe successfully merged lines may be uninteresting from the point of\ndeciding what I should *do* but they\nare highly relevant to the question of what I really, really should *not* do.\n\nIf there are 100 successfully merged lines from each side of the merge\nbut only 2 conflicting lines, should I\n\na) pick the remote branch\nb) pick the local branch\nc) manually edit the conflicting line (or use a merge tool)\n\nThe point of my patch it to make it much more likely that you will pick c).\n\nIn the current state, the GUI doesn't make it clear that either a) or\nb) is almost certainly a huge mistake.\n\nNow, you could disable Use Remote and Use Local for all but the very\nsimplest cases - but you don't need it for these\ncases. Hell, ed would do for these.\n\njon.\n"},{"id":"138275","messageId":"4BB3346C.7070700@viscovery.net","threadId":"23251","inReplyTo":"k2p2cfc40321003310412hf4c6d642n4349af3f644829ff@mail.gmail.com","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-31T11:39:24Z","receivedAt":"2010-03-31T11:39:24Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/31/2010 13:12, schrieb Jon Seymour:\n>> I looked at the result, but it does not convince me. In my case, I have a\n>> large file that has many changes between the \"maint\" and \"master\"\n>> branches. Whenever there are conflicts after merging \"maint\" to \"master\",\n>> I see all these changes, and really they *are* uninteresting.\n>>\n> \n> I think you may have missed the point of my patch.\n> \n> The successfully merged lines may be uninteresting from the point of\n> deciding what I should *do* but they\n> are highly relevant to the question of what I really, really should *not* do.\n\nHow would you decide that if you cannot read the information that is\npresented to you?\n\nCan you tell without thinking for 10 seconds which of these two changes is\nlost if you choose \"Use local version\"?\n\n@@@ ... @@@\n  x\n +foo\n  y\n@@@ ... @@@\n  a\n- bar\n  b\n\nOh, it's easy for the conflicted part of the diff, which you'll see\nelsewhere as well:\n\n@@@ ... @@@\n  r\n++<<<<<<< HEAD\n +foo\n++=======\n+ bar\n++>>>>>>> some-branch\n  s\n\nDo not forget that in a case (like mine) where the non-condensed diff is\nactually huge, the conflict markers would no exactly be easy to find in\nthe diff.\n\n> If there are 100 successfully merged lines from each side of the merge\n> but only 2 conflicting lines, should I\n> \n> a) pick the remote branch\n> b) pick the local branch\n> c) manually edit the conflicting line (or use a merge tool)\n> \n> The point of my patch it to make it much more likely that you will pick c).\n\nAnd I was saying almost the same, namely that it should not only be \"much\nmore likely\" to pick c, but to *always* pick c (by making it the only\noption available).\n\n> In the current state, the GUI doesn't make it clear that either a) or\n> b) is almost certainly a huge mistake.\n\nAnd therefore I suggest to disable these options.\n\n> Now, you could disable Use Remote and Use Local for all but the very\n> simplest cases - but you don't need it for these\n> cases. Hell, ed would do for these.\n\nWhich are those very simplest cases that you are referring to? If you mean\nmodify/delete conflicts, then I indeed would like to keep the options for\nthem.\n\nThat said, your earlier patch that presented the diff against HEAD was not\nbad after all.\n\n-- Hannes\n"},{"id":"138277","messageId":"l2z2cfc40321003310450p51363facu1142c665512d6825@mail.gmail.com","threadId":"23251","inReplyTo":"4BB3346C.7070700@viscovery.net","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-31T11:50:02Z","receivedAt":"2010-03-31T11:50:02Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Mar 31, 2010 at 11:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Am 3/31/2010 13:12, schrieb Jon Seymour:\n>>> I looked at the result, but it does not convince me. In my case, I have a\n>>> large file that has many changes between the \"maint\" and \"master\"\n>>> branches. Whenever there are conflicts after merging \"maint\" to \"master\",\n>>> I see all these changes, and really they *are* uninteresting.\n>>>\n>>\n>> I think you may have missed the point of my patch.\n>>\n>> The successfully merged lines may be uninteresting from the point of\n>> deciding what I should *do* but they\n>> are highly relevant to the question of what I really, really should *not* do.\n>\n> How would you decide that if you cannot read the information that is\n> presented to you?\n>\n> Can you tell without thinking for 10 seconds which of these two changes is\n> lost if you choose \"Use local version\"?\n>\n> @@@ ... @@@\n>  x\n>  +foo\n>  y\n> @@@ ... @@@\n>  a\n> - bar\n>  b\n>\n> Oh, it's easy for the conflicted part of the diff, which you'll see\n> elsewhere as well:\n>\n> @@@ ... @@@\n>  r\n> ++<<<<<<< HEAD\n>  +foo\n> ++=======\n> + bar\n> ++>>>>>>> some-branch\n>  s\n>\n> Do not forget that in a case (like mine) where the non-condensed diff is\n> actually huge, the conflict markers would no exactly be easy to find in\n> the diff.\n\nBut that's exactly the point - not to make the choice easy, but to\nmake it obvious that the choice is *not easy*.\n\nThe problem is that as it stands the user things the only choice is\nbetween choosing \"foo\" and choosing \"bar\".\n\n> ++<<<<<<< HEAD\n>  +foo\n> ++=======\n> + bar\n> ++>>>>>>> some-branch\n\nThis is a false choice but it is not obviously so.\n\nThe point of using diff -c is *precisely* to help the user understand\nthat it isn't a choice between foo and bar, but a choice\nbetween losing all the changes that came with foo and all the changes\nthat came with bar.\n\n\n> And therefore I suggest to disable these options.\n>\n\nI agree that this would be a better solution than leaving the behaviour as is.\n\n> Which are those very simplest cases that you are referring to? If you mean\n> modify/delete conflicts, then I indeed would like to keep the options for\n> them.\n\nThe simplest case is when the presented diff presents the *whole*\ndifference between the local and remote branches.\n\nAs it stands, the gui can mislead the user into believing that the\npresented diff is the whole difference and that their only\nchoice is between foo and bar.\n\nSure, users who have been bitten by this misapprehension will learn,\nbut it is hard lesson to learn.\n\n>\n> That said, your earlier patch that presented the diff against HEAD was not\n> bad after all.\n\nI prefer the -c version - not because the output is easy to\nunderstand, but precisely because it gives pause.\n\njon.\n"},{"id":"138283","messageId":"t2u2cfc40321003310523u8fda9baeo883d2e0b3c6fa807@mail.gmail.com","threadId":"23251","inReplyTo":"4BB3346C.7070700@viscovery.net","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-31T12:23:17Z","receivedAt":"2010-03-31T12:23:17Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"What about the safe (but complicated) diff -c by default (to prevent\nmisinformed Use Remote/Local decisions, by default) and a \"Conflicts\nOnly\" option (disabled by default) that shows the diff --cc output for\nthose who know what they are doing?\n\njon.\n\nOn Wed, Mar 31, 2010 at 11:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Am 3/31/2010 13:12, schrieb Jon Seymour:\n>>> I looked at the result, but it does not convince me. In my case, I have a\n>>> large file that has many changes between the \"maint\" and \"master\"\n>>> branches. Whenever there are conflicts after merging \"maint\" to \"master\",\n>>> I see all these changes, and really they *are* uninteresting.\n>>>\n>>\n>> I think you may have missed the point of my patch.\n>>\n>> The successfully merged lines may be uninteresting from the point of\n>> deciding what I should *do* but they\n>> are highly relevant to the question of what I really, really should *not* do.\n>\n> How would you decide that if you cannot read the information that is\n> presented to you?\n>\n> Can you tell without thinking for 10 seconds which of these two changes is\n> lost if you choose \"Use local version\"?\n>\n> @@@ ... @@@\n>  x\n>  +foo\n>  y\n> @@@ ... @@@\n>  a\n> - bar\n>  b\n>\n> Oh, it's easy for the conflicted part of the diff, which you'll see\n> elsewhere as well:\n>\n> @@@ ... @@@\n>  r\n> ++<<<<<<< HEAD\n>  +foo\n> ++=======\n> + bar\n> ++>>>>>>> some-branch\n>  s\n>\n> Do not forget that in a case (like mine) where the non-condensed diff is\n> actually huge, the conflict markers would no exactly be easy to find in\n> the diff.\n>\n>> If there are 100 successfully merged lines from each side of the merge\n>> but only 2 conflicting lines, should I\n>>\n>> a) pick the remote branch\n>> b) pick the local branch\n>> c) manually edit the conflicting line (or use a merge tool)\n>>\n>> The point of my patch it to make it much more likely that you will pick c).\n>\n> And I was saying almost the same, namely that it should not only be \"much\n> more likely\" to pick c, but to *always* pick c (by making it the only\n> option available).\n>\n>> In the current state, the GUI doesn't make it clear that either a) or\n>> b) is almost certainly a huge mistake.\n>\n> And therefore I suggest to disable these options.\n>\n>> Now, you could disable Use Remote and Use Local for all but the very\n>> simplest cases - but you don't need it for these\n>> cases. Hell, ed would do for these.\n>\n> Which are those very simplest cases that you are referring to? If you mean\n> modify/delete conflicts, then I indeed would like to keep the options for\n> them.\n>\n> That said, your earlier patch that presented the diff against HEAD was not\n> bad after all.\n>\n> -- Hannes\n>\n"},{"id":"138288","messageId":"4BB3534E.3080803@viscovery.net","threadId":"23251","inReplyTo":"t2u2cfc40321003310523u8fda9baeo883d2e0b3c6fa807@mail.gmail.com","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-31T13:51:10Z","receivedAt":"2010-03-31T13:51:10Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/31/2010 14:23, schrieb Jon Seymour:\n> What about the safe (but complicated) diff -c by default (to prevent\n> misinformed Use Remote/Local decisions, by default) and a \"Conflicts\n> Only\" option (disabled by default) that shows the diff --cc output for\n> those who know what they are doing?\n\nYou would like to have the worst of all three?\n\n1. dangerous menu options\n2. incomprehensible diff -c output\n3. and a config option on top of it\n\nI think we should have none of them.\n\nYes, I suggested diff -c, but after seeing how it works (better: not\nworks), I changed my mind.\n\nWhat sort of user guidance is it to present alluring menu options \"Use\nlocal/remote version\", but at the same time a scaring amount of diff -c\noutput.\n\n-- Hannes\n"},{"id":"138304","messageId":"v2z2cfc40321003311252s86d44ad7l540559eafb0636d4@mail.gmail.com","threadId":"23251","inReplyTo":"4BB3534E.3080803@viscovery.net","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-03-31T19:52:44Z","receivedAt":"2010-03-31T19:52:44Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"| apologies - missed the list\n\nI agree that removing the options is better than preserving the\ncurrent behaviour,\n\nMy argument is simply this:\n\nThat it is better to inform a user that an action is potentially\ndangerous than to \"protect\" them from\na \"scaring\" amount of diff -c output by presenting a conflict-only\nsummary. You claimed this output was \"uninteresting\" and hence should\nbe suppressed, my point was that supresssing output because it was\n\"uninteresting\" is a dangerous thing to do because it is relevant to a\ndecision not to act.\n\nMy preference for options are:\n\n* preserve the actions, but provide more information to the user\n* remove the actions\n* preserve the actions, make the safer output the default and enable\nthe simpler, more dangerous output as an option\n* preserve the actions, make the current output the default and enable\nthe safer, less dangerous output an option.\n* do nothing\n\nWe disagree about the relative order of options 1 and 2. But\nseriously, if you agree the actions are dangerous I can't see how you\ncan argue that is preferable to suppress the scary amount of diff -c\noutput.\n\nI would imagine that a change that proposed to remove the actions,\nwithout an option to enable them, would encounter stiff resistance\nfrom the list. However, perhaps the list can respond?\n\njon.\n"},{"id":"138410","messageId":"4BB5ACD3.10307@viscovery.net","threadId":"23251","inReplyTo":"v2z2cfc40321003311252s86d44ad7l540559eafb0636d4@mail.gmail.com","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-04-02T08:37:39Z","receivedAt":"2010-04-02T08:37:39Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 31.03.2010 21:52, schrieb Jon Seymour:\n> I agree that removing the options is better than preserving the\n> current behaviour,\n\nSo, we are in agreement in this. Suppose we do remove them. What remains \nthat is dangerous?\n\nThe user has no option to accidentally revert changes that are not \ndisplayed even if the current diff --cc remains. The user is forced to run \nmergetool or to go to the editor.\n\nIt is now an orthogonal matter whether diff --cc is helpful. Here I do \nagree somewhat that diff against HEAD is more helpful than the current \ndiff --cc.\n\n> I would imagine that a change that proposed to remove the actions,\n> without an option to enable them, would encounter stiff resistance\n> from the list. However, perhaps the list can respond?\n\nWho knows? There was not a lot discussion when the feature was presented \nto the list, not even a word of excitement.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/94425/focus=94426\n\n-- Hannes\n"},{"id":"138525","messageId":"o2m2cfc40321004032344of94fa946je6c1865cffccd69@mail.gmail.com","threadId":"23251","inReplyTo":"4BB5ACD3.10307@viscovery.net","subject":"Re: [PATCH v3 0/2] git-gui: change to display the combined diff in the case of conflicts.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-04-04T06:44:57Z","receivedAt":"2010-04-04T06:44:57Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, Apr 2, 2010 at 7:37 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Am 31.03.2010 21:52, schrieb Jon Seymour:\n>>\n>> I agree that removing the options is better than preserving the\n>> current behaviour,\n>\n> So, we are in agreement in this. Suppose we do remove them. What remains\n> that is dangerous?\n\nStage to commit is still somewhat dangerous if the current \"diff\"\noutput is displayed because all the successfully staged changes\nalready in the index that will be purged by the \"Stage to commit\"\naction will still not be visible until after the action is taken -\nhence the original suggestion to use the \"diff HEAD\" output.\n\n>\n> The user has no option to accidentally revert changes that are not displayed\n> even if the current diff --cc remains. The user is forced to run mergetool\n> or to go to the editor.\n>\n> It is now an orthogonal matter whether diff --cc is helpful. Here I do agree\n> somewhat that diff against HEAD is more helpful than the current diff --cc.\n\nI am not sure the issues are completely orthogonal since I would still\nargue that in the case the \"Use Local/Use Remote\" actions are\npreserved, the diff -c output is the only output that provides enough\ninformation to inform the user of the likely consequences of taking\neach action. [ rationale: diff HEAD allows the consequences of Use\nLocal to be assessed, but does not allow the consequences of Use\nRemote to be adequately assessed. ] That said, I agree that\nthe \"diff HEAD\" output is still better than the current \"diff\" output\nin this situation since it does at least tell you want \"Stage to\ncommit\" will do with respect to the current HEAD (if not with respect\nto successfully staged changes in the index).\n\nI agree in the case that the \"Use Local/Remote\" actions are removed\nfrom the UI, then the only remaining action of consequence is \"Stage\nto commit\" and that for this \"diff HEAD\" output is the most\nappropriate output to use in order to evaluate the expected\nconsequences of taking that action.\n\nUntil such time as I see some indication that Shawn will accept a\n\"Remove Use ... actions\" patch, I'll assume that he won't. I will\nlikely re-roll the existing patch so that the user can choose via\nconfiguration the diff options to be used for merge conflicts so that\npeople who don't like \"diff -c\" output can configure it to use \"diff\nHEAD\" output instead.\n\n>\n>> I would imagine that a change that proposed to remove the actions,\n>> without an option to enable them, would encounter stiff resistance\n>> from the list. However, perhaps the list can respond?\n>\n> Who knows? There was not a lot discussion when the feature was presented to\n> the list, not even a word of excitement.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/94425/focus=94426\n>\n\nTrue. Perhaps I should submit a \"git-gui: Remove Use Remote/Local\nactions\" patch just to generate some excitement?\n\nShawn: any thoughts on any of this?\n\njon.\n\n> -- Hannes\n>\n"}]}