{"thread":{"id":"14592","subject":"Re: [PATCH] bring description of git diff --cc up to date","startedAt":"2008-07-22T16:19:47Z","lastAt":"2008-07-24T00:35:07Z","messageCount":8,"participants":["Jonathan Nieder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"84330","messageId":"20080722111947.BIW29914@m4500-01.uchicago.edu","threadId":"14592","inReplyTo":null,"subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Jonathan Nieder","fromEmail":"jrnieder@uchicago.edu","sentAt":"2008-07-22T16:19:47Z","receivedAt":"2008-07-22T16:19:47Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Jonathan Nieder writes:\n>\n>> +\tThis flag implies the '-c' option and makes the patch output\n>> +\teven more compact by omitting uninteresting hunks. A hunk is\n>> +\tconsidered interesting only if either (a) it shows changes from\n>> +\tall parents or (b) in an Octopus merge, it shows different changes\n>> +\tfrom at least three different parents.\n>\n> I am not sure where that \"at lesta three different parents\" comes from.\n> It might be that what the logic does can be expressed that way, but that\n> was not the guiding principle why the code does what it currently does.\n\nYes, exactly - this is what I meant in saying \"my proposed text\ndoes not suggest very strongly what --cc is intended to do\". I\nhaven't found any wording yet that both makes it clear what --cc\nactually does and follows a thought process suggesting why.\n\nJust to make sure I understand, here is what I think --cc does:\n\n - In a two-parent merge, it is exactly as Linus has been\n describing it. A hunk is interesting if and only if\n it shows changes from both parents.\n\n - In a many-parent merge, the criterion is more stringent.\n As in the two-parent merge case, the hunk must show no\n changes from at least one of the parents, meaning that\n one of several alternatives for that portion of code\n was chosen by the code integrator (without mixing and\n matching or adding additional changes); but further, there\n must have been only two alternatives for that portion of\n code to choose between. If there were three distinct\n alternatives, no matter what the code integrator does, the\n hunk will show up (because that is so rare and deserves\n attention).\n\nIs that correct?\n\nThanks for the reading matter. If it stimulates anyone reading\ninto coming up with a better description, they should please let\nme know :)\n"},{"id":"84340","messageId":"7v63qxn8w2.fsf@gitster.siamese.dyndns.org","threadId":"14592","inReplyTo":"20080722111947.BIW29914@m4500-01.uchicago.edu","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-22T17:09:17Z","receivedAt":"2008-07-22T17:09:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Just to make sure I understand, here is what I think --cc does:\n>\n> - In a two-parent merge, it is exactly as Linus has been\n> ...\n> - In a many-parent merge, the criterion is more stringent.\n> ...\n>\n> Is that correct?\n\nThe logic in the code does not have separate criteria for two-parent and\nOctopus cases. Actually Linus talks about \"when you have two versions to\nchoose from, and if the result matches one of them, then it is not\ninteresting\". In a two-parent merge, you cannot have three or more\npossible versions to choose from by definition, can you?\n"},{"id":"84374","messageId":"7vd4l5lio1.fsf@gitster.siamese.dyndns.org","threadId":"14592","inReplyTo":"7v63qxn8w2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-22T21:21:02Z","receivedAt":"2008-07-22T21:21:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jonathan Nieder writes:\n>\n>> Just to make sure I understand, here is what I think --cc does:\n>>\n>> - In a two-parent merge, it is exactly as Linus has been\n>> ...\n>> - In a many-parent merge, the criterion is more stringent.\n>> ...\n>>\n>> Is that correct?\n>\n> The logic in the code does not have separate criteria for two-parent and\n> Octopus cases. Actually Linus talks about \"when you have two versions to\n> choose from, and if the result matches one of them, then it is not\n> interesting\". In a two-parent merge, you cannot have three or more\n> possible versions to choose from by definition, can you?\n\nTo put it another way, I think what you wrote is correct, but two-parent\ncase is just a degenerated case of a more general rule, that is:\n\n A hunk is not interesting if the person who merged had only two\n choices offered by the parents to pick from, and the merge result\n exactly matched one of the choices.\n\nYou can come up with examples that do not match the above criteria; they\nare all interesting.\n\nFor example, if all the parent of a tripus disagreed, the person had more\nthan two choices to pick from, so no matter what the resolution is, the\nhunk is interesting.\n\nOn the other hand, if 4 parents in a dodecapus lack a line that all other\n8 parents have (see the first example in [*1*]), then the choice for the\nperson who merges these 12 parents is either to include or not include\nthat line. If the line was included, it is not interesting. If the line\nwas deleted (which is different from what happened in *1*), it is not\ninteresting, either.\n\nOne thing to note is \"have only two choices to pick from\" does not have a\ndirect connection to two-parent-ness. In a two-parent merge (di-pus?), by\ndefinition you cannot have more than two choices, but that is not any\ndifferent from a Dodecapus that has only two groups of parents. Most\noctopus merges have only two groups of parents like the \"merge from hell\"\ndoes when we talk about individual paths (otherwise it would be very\npainful to resolve so it is not done in practice).\n\n[Reference]\n\n*1* http://article.gmane.org/gmane.comp.version-control.git/15487\n"},{"id":"84401","messageId":"Pine.GSO.4.62.0807221812470.25746@harper.uchicago.edu","threadId":"14592","inReplyTo":"7vd4l5lio1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Jonathan Nieder","fromEmail":"jrnieder@uchicago.edu","sentAt":"2008-07-22T23:27:18Z","receivedAt":"2008-07-22T23:27:18Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Actually Linus talks about \"when you have two versions to\n> choose from, and if the result matches one of them, then it is not\n> interesting\".\n\nThat is much better - thanks. (The description by Linus I was referring\nto was from\n:\n\"So \"--cc\" only shows output if: the merge itself actually changed\nsomething from _all_ parents\" - which is not too misleading since the\ntwo-parent case is the usual one.)\n\nHow about this, then?\n--- %< ---\nSubject: document diff --cc's long-ago-changed semantics\n\nIn February 2006 [1], the definition of \"interesting hunk\" for\ngit's \"compact combined diff\" format changed, without any\ncorresponding change in documentation. This patch brings the\ndocumentation up to date.\n\n[1] commit bf1c32bdec8223785c779779d0a660a099f69a63\n combine-diff: update --cc \"uninteresting hunks\" logic\n---\n Documentation/git-diff-tree.txt | 12 +++++++-----\n Documentation/rev-list-options.txt | 9 +++++----\n 2 files changed, 12 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt\nindex 0e45b58..14dc70d 100644\n--- a/Documentation/git-diff-tree.txt\n+++ b/Documentation/git-diff-tree.txt\n@@ -92,12 +92,14 @@ include::pretty-options.txt[]\n --cc::\n \tThis flag changes the way a merge commit patch is displayed,\n \tin a similar way to the '-c' option. It implies the '-c'\n-\tand '-p' options and further compresses the patch output\n-\tby omitting hunks that show differences from only one\n-\tparent, or show the same change from all but one parent\n-\tfor an Octopus merge. When this optimization makes all\n+\tand '-p' options and makes the patch output\n+\teven more compact by omitting uninteresting hunks. A hunk is\n+\tconsidered uninteresting if the person merging had two versions\n+\tto choose between among all of the parents and the result shows\n+\tno changes from one of those versions.\n+\tWhen this optimization makes all\n \thunks disappear, the commit itself and the commit log\n-\tmessage is not shown, just like in any other \"empty diff\" case.\n+\tmessage are not shown, just like in any other \"empty diff\" case.\n \n --always::\n \tShow the commit itself and the commit log message even\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex b6f5d87..c61d05d 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -111,10 +111,11 @@ options may be given. See linkgit:git-diff-files[1] for more options.\n \n --cc::\n \n-\tThis flag implies the '-c' options and further compresses the\n-\tpatch output by omitting hunks that show differences from only\n-\tone parent, or show the same change from all but one parent for\n-\tan Octopus merge.\n+\tThis flag implies the '-c' option and makes the patch output\n+\teven more compact by omitting uninteresting hunks. A hunk is\n+\tconsidered uninteresting if the person merging had two versions\n+\tto choose between among all of the parents and the result shows\n+\tno changes from one of those versions.\n \n -r::\n \n-- \n1.5.6.3.549.g8ca11\n"},{"id":"84414","messageId":"7vfxq1igh0.fsf@gitster.siamese.dyndns.org","threadId":"14592","inReplyTo":"Pine.GSO.4.62.0807221812470.25746@harper.uchicago.edu","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T00:36:43Z","receivedAt":"2008-07-23T00:36:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> +\tThis flag implies the '-c' option and makes the patch output\n> +\teven more compact by omitting uninteresting hunks. A hunk is\n> +\tconsidered uninteresting if the person merging had two versions\n> +\tto choose between among all of the parents and the result shows\n\nHmm, I am not a native speaker, but the above makes me confused into\nthinking that even if there are 47 parent versions, it is Ok if I looked\nat only two versions and picked from one of them -- the description does\nnot seem to make it clear that it is required that the other 45 agree with\none of the two I looked at and picked from.\n\n ... if the contents in the parents had only two variants and the merge\n result picked one of them without modification.\n\nwould be succinct enough, perhaps?\n\nIf we want to further elaborate, we could say something like:\n\n In a two-parent merge, by definition, there can only be two variants\n to choose from. Even in a merge with more than two parents, if some\n parents share the same content, and all the other parents share\n another, same content, there are only two variants to choose from.\n\nbut I think that is too verbose...\n"},{"id":"84436","messageId":"Pine.GSO.4.62.0807222210540.3408@harper.uchicago.edu","threadId":"14592","inReplyTo":"7vfxq1igh0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Jonathan Nieder","fromEmail":"jrnieder@uchicago.edu","sentAt":"2008-07-23T03:55:06Z","receivedAt":"2008-07-23T03:55:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"On Tue, 22 Jul 2008, Junio C Hamano wrote:\n\n>> +\tThis flag implies the '-c' option and makes the patch output\n>> +\teven more compact by omitting uninteresting hunks. A hunk is\n>> +\tconsidered uninteresting if the person merging had two versions\n>> +\tto choose between among all of the parents and the result shows\n>\n> the above makes me confused into\n> thinking that even if there are 47 parent versions, it is Ok if I looked\n> at only two versions and picked from one of them\n\nHere's another attempt. I grimace at the sound of it, but it might be\nmore clear.\n\n--- snipsnip ---\nSubject: document diff --cc's long-ago-changed semantics\n\nIn February 2006 [1], the definition of \"interesting hunk\" for\ngit's compact-combined diff format changed without a\ncorresponding change in documentation. This patch brings the\ndocumentation up to date.\n\n[1] commit bf1c32bdec8223785c779779d0a660a099f69a63\n combine-diff: update --cc \"uninteresting hunks\" logic\n\nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-diff-tree.txt | 12 +++++++-----\n Documentation/rev-list-options.txt | 9 +++++----\n 2 files changed, 12 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt\nindex 0e45b58..7f8dc5b 100644\n--- a/Documentation/git-diff-tree.txt\n+++ b/Documentation/git-diff-tree.txt\n@@ -92,12 +92,14 @@ include::pretty-options.txt[]\n --cc::\n \tThis flag changes the way a merge commit patch is displayed,\n \tin a similar way to the '-c' option. It implies the '-c'\n-\tand '-p' options and further compresses the patch output\n-\tby omitting hunks that show differences from only one\n-\tparent, or show the same change from all but one parent\n-\tfor an Octopus merge. When this optimization makes all\n+\tand '-p' options and makes the patch output\n+\teven more compact by omitting uninteresting hunks. A hunk is\n+\tconsidered uninteresting if it shows no changes from at least\n+\tone of the parents and shows the same changes from each of the\n+\tparents from which it shows changes.\n+\tWhen this optimization makes all\n \thunks disappear, the commit itself and the commit log\n-\tmessage is not shown, just like in any other \"empty diff\" case.\n+\tmessage are not shown, just like in any other \"empty diff\" case.\n \n --always::\n \tShow the commit itself and the commit log message even\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex b6f5d87..d75de78 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -111,10 +111,11 @@ options may be given. See linkgit:git-diff-files[1] for more options.\n \n --cc::\n \n-\tThis flag implies the '-c' options and further compresses the\n-\tpatch output by omitting hunks that show differences from only\n-\tone parent, or show the same change from all but one parent for\n-\tan Octopus merge.\n+\tThis flag implies the '-c' option and makes the patch output\n+\teven more compact by omitting uninteresting hunks. A hunk is\n+\tconsidered uninteresting if it shows no changes from at least\n+\tone of the parents and shows the same changes from each of the\n+\tparents from which it shows changes.\n \n -r::\n \n-- \n1.5.6.3.549.g8ca11\n"},{"id":"84639","messageId":"7v3am09oqe.fsf@gitster.siamese.dyndns.org","threadId":"14592","inReplyTo":"Pine.GSO.4.62.0807222210540.3408@harper.uchicago.edu","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T23:15:21Z","receivedAt":"2008-07-23T23:15:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> On Tue, 22 Jul 2008, Junio C Hamano wrote:\n>\n> Here's another attempt. I grimace at the sound of it, but it might be\n> more clear.\n\nLet's just do this. I think it is clear enough.\n\n Documentation/git-diff-tree.txt | 10 +++++-----\n Documentation/rev-list-options.txt | 6 +++---\n 2 files changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt\nindex 0e45b58..8c8f35b 100644\n--- a/Documentation/git-diff-tree.txt\n+++ b/Documentation/git-diff-tree.txt\n@@ -93,11 +93,11 @@ include::pretty-options.txt[]\n \tThis flag changes the way a merge commit patch is displayed,\n \tin a similar way to the '-c' option. It implies the '-c'\n \tand '-p' options and further compresses the patch output\n-\tby omitting hunks that show differences from only one\n-\tparent, or show the same change from all but one parent\n-\tfor an Octopus merge. When this optimization makes all\n-\thunks disappear, the commit itself and the commit log\n-\tmessage is not shown, just like in any other \"empty diff\" case.\n+\tby omitting uninteresting hunks whose the contents in the parents\n+\thave only two variants and the merge result picks one of them\n+\twithout modification. When all hunks are uninteresting, the commit\n+\titself and the commit log message is not shown, just like in any other\n+\t\"empty diff\" case.\n \n --always::\n \tShow the commit itself and the commit log message even\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex b6f5d87..3aa3809 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -112,9 +112,9 @@ options may be given. See linkgit:git-diff-files[1] for more options.\n --cc::\n \n \tThis flag implies the '-c' options and further compresses the\n-\tpatch output by omitting hunks that show differences from only\n-\tone parent, or show the same change from all but one parent for\n-\tan Octopus merge.\n+\tpatch output by omitting uninteresting hunks whose contents in\n+\tthe parents have only two variants and the merge result picks\n+\tone of them without modification.\n \n -r::\n \n"},{"id":"84657","messageId":"Pine.GSO.4.62.0807231933000.13433@harper.uchicago.edu","threadId":"14592","inReplyTo":"7v3am09oqe.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bring description of git diff --cc up to date","fromName":"Jonathan Nieder","fromEmail":"jrnieder@uchicago.edu","sentAt":"2008-07-24T00:35:07Z","receivedAt":"2008-07-24T00:35:07Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Let's just do this. I think it is clear enough.\n\nWorks for me. Thanks, and sorry I dragged this on so.\n"}]}