{"thread":{"id":"54839","subject":"[RFC/PATCH] mergetool: use resolved conflicts in all the views","startedAt":"2020-12-16T17:44:32Z","lastAt":"2020-12-28T14:28:17Z","messageCount":70,"participants":["Felipe Contreras","Junio C Hamano","Seth House","Johannes Sixt","David Aguilar","Pratyush Yadav","Ævar Arnfjörð Bjarmason","Randall S. Becker"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"412378","messageId":"20201216174345.28146-1-felipe.contreras@gmail.com","threadId":"54839","inReplyTo":null,"subject":"[RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-16T17:43:45Z","receivedAt":"2020-12-16T17:44:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It doesn't make sense to display already-resolved conflicts in the\ndifferent views of all mergetools.\n\nWe already have the best version in MERGED, with annotations that can\nbe used to extract a pruned version of LOCAL and REMOTE. If we are using\nthe diff3 conflict-style, we can even extract BASE.\n\nLet's use these annotations instead of using the original files before\nthe conflict resolution.\n\nTODO: There may be a better way to extract these files that doesn't rely\non the user's conflict-style configuration.\n\nSee Seth House's blog post [1] for the idea and the rationale.\n\n[1] https://www.eseth.org/2020/mergetools.html\n\nCc: Seth House \nSigned-off-by: Felipe Contreras \n---\n git-mergetool.sh | 19 ++++---------------\n 1 file changed, 4 insertions(+), 15 deletions(-)\n\ndiff --git a/git-mergetool.sh b/git-mergetool.sh\nindex e3f6d543fb..4759433d46 100755\n--- a/git-mergetool.sh\n+++ b/git-mergetool.sh\n@@ -227,18 +227,6 @@ stage_submodule () {\n \tgit update-index --add --replace --cacheinfo 160000 \"$submodule_sha1\" \"${work_rel_path%/}\" || die\n }\n \n-checkout_staged_file () {\n-\ttmpfile=\"$(git checkout-index --temp --stage=\"$1\" \"$2\" 2>/dev/null)\" &&\n-\ttmpfile=${tmpfile%%'\t'*}\n-\n-\tif test $? -eq 0 && test -n \"$tmpfile\"\n-\tthen\n-\t\tmv -- \"$(git rev-parse --show-cdup)$tmpfile\" \"$3\"\n-\telse\n-\t\t>\"$3\"\n-\tfi\n-}\n-\n merge_file () {\n \tMERGED=\"$1\"\n \n@@ -318,9 +306,10 @@ merge_file () {\n \t# where the base's directory no longer exists.\n \tmkdir -p \"$(dirname \"$MERGED\")\"\n \n-\tcheckout_staged_file 1 \"$MERGED\" \"$BASE\"\n-\tcheckout_staged_file 2 \"$MERGED\" \"$LOCAL\"\n-\tcheckout_staged_file 3 \"$MERGED\" \"$REMOTE\"\n+\t# TODO: How do we get $MERGED always with diff3?\n+\tsed -e '/^<<<<<<< /,/^||||||| /d' -e '/^=======$/,/^>>>>>>> /d' \"$MERGED\" > \"$BASE\"\n+\tsed -e '/^<<<<<<< /,/^=======$/d' -e '/^>>>>>>> /d' \"$MERGED\" > \"$LOCAL\"\n+\tsed -e '/^||||||| /,/^>>>>>>> /d' -e '/^<<<<<<< /d' \"$MERGED\" > \"$REMOTE\"\n \n \tif test -z \"$local_mode\" || test -z \"$remote_mode\"\n \tthen\n-- \n2.30.0.rc0\n\n"},{"id":"412440","messageId":"xmqqa6ud2xuw.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"20201216174345.28146-1-felipe.contreras@gmail.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-16T22:24:23Z","receivedAt":"2020-12-16T22:25:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> It doesn't make sense to display already-resolved conflicts in the\n> different views of all mergetools.\n>\n> We already have the best version in MERGED, with annotations that can\n> be used to extract a pruned version of LOCAL and REMOTE. If we are using\n> the diff3 conflict-style, we can even extract BASE.\n>\n> Let's use these annotations instead of using the original files before\n> the conflict resolution.\n>\n> TODO: There may be a better way to extract these files that doesn't rely\n> on the user's conflict-style configuration.\n>\n> See Seth House's blog post [1] for the idea and the rationale.\n>\n> [1] https://www.eseth.org/2020/mergetools.html\n>\n> Cc: Seth House \n> Signed-off-by: Felipe Contreras \n\nHmph, I got what Seth showed, but I do not quite see how the ideas\nin the post relate to what this patch does. The patch just avoids\ngrabbing the contents of each stage out to a file for three stages\nusing \"git checkout-index\" and instead does the same by munging the\ndiff3 output, which ought to have the same information at least for\ntext files, using \"sed\", or is there something I am not seeing?\n\nIf there is none, then what is the benefit of doing the same thing\nwithout running 3 checkout-index? Performance?\n\nAlso using checkout-index to grab the raw contents without relying\non the textual context marker would mean that a custom mergetool\nbackend could be used to merge non-text files. So if this\noptimization (I am still assuming this is \"doing the same without\nrunning three checkout-index to gain performance\" I read out of the\npatch text) is worth doing, there needs a knob to allow users to opt\nout of it somehow to avoid regressing on the feature front.\n\nIf the mergetool were in control to (re)start the merge process that\nwould result in the conflicted state, we could override the end-user\npreference on the conflict style (either 'GNU merge'-style or\n'diff3'-style) and conflict-marker-length to be used in showing\ntextual conflicts, but as I understand \"mergetool\" is handed an\nalready conflicted state and asked to resolve it, it would not be\npossible without at least looking at the stage #1 to recover the\nbase for folks who do not use diff3 style.\n\n> ---\n> git-mergetool.sh | 19 ++++---------------\n> 1 file changed, 4 insertions(+), 15 deletions(-)\n>\n> diff --git a/git-mergetool.sh b/git-mergetool.sh\n> index e3f6d543fb..4759433d46 100755\n> --- a/git-mergetool.sh\n> +++ b/git-mergetool.sh\n> @@ -227,18 +227,6 @@ stage_submodule () {\n> \tgit update-index --add --replace --cacheinfo 160000 \"$submodule_sha1\" \"${work_rel_path%/}\" || die\n> }\n> \n> -checkout_staged_file () {\n> -\ttmpfile=\"$(git checkout-index --temp --stage=\"$1\" \"$2\" 2>/dev/null)\" &&\n> -\ttmpfile=${tmpfile%%'\t'*}\n> -\n> -\tif test $? -eq 0 && test -n \"$tmpfile\"\n> -\tthen\n> -\t\tmv -- \"$(git rev-parse --show-cdup)$tmpfile\" \"$3\"\n> -\telse\n> -\t\t>\"$3\"\n> -\tfi\n> -}\n> -\n> merge_file () {\n> \tMERGED=\"$1\"\n> \n> @@ -318,9 +306,10 @@ merge_file () {\n> \t# where the base's directory no longer exists.\n> \tmkdir -p \"$(dirname \"$MERGED\")\"\n> \n> -\tcheckout_staged_file 1 \"$MERGED\" \"$BASE\"\n> -\tcheckout_staged_file 2 \"$MERGED\" \"$LOCAL\"\n> -\tcheckout_staged_file 3 \"$MERGED\" \"$REMOTE\"\n> +\t# TODO: How do we get $MERGED always with diff3?\n> +\tsed -e '/^<<<<<<< /,/^||||||| /d' -e '/^=======$/,/^>>>>>>> /d' \"$MERGED\" > \"$BASE\"\n> +\tsed -e '/^<<<<<<< /,/^=======$/d' -e '/^>>>>>>> /d' \"$MERGED\" > \"$LOCAL\"\n> +\tsed -e '/^||||||| /,/^>>>>>>> /d' -e '/^<<<<<<< /d' \"$MERGED\" > \"$REMOTE\"\n> \n\nStyle (lose SP after '>' redirection; I looked at the existing code\nand spotted one existing violation but that is not an excuse to make\nthings even less consistent).\n\nAlso, conflict-marker-size= attributes can change the length, so\nhardcoding these patterns would not work for everybody.\n\n> \tif test -z \"$local_mode\" || test -z \"$remote_mode\"\n> \tthen\n\nThanks.\n"},{"id":"412451","messageId":"105041520.23756286.1608159189934.JavaMail.zimbra@eseth.com","threadId":"54839","inReplyTo":"xmqqa6ud2xuw.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-16T22:53:09Z","receivedAt":"2020-12-16T23:28:44Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"I appreciate Felipe getting the discussion started.\n\nOn Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote:\n> If there is none, then what is the benefit of doing the same thing\n> without running 3 checkout-index?\n\nI wasn't aware of this plubming when I wrote the initial shell-script\nversion of the technique. This is a much better approach (even *if*\nthere's a negligible performance penalty). This nicely avoids\nUNIX/Windows line-ending surprises, and instead leans on\nalready-configured Git defaults for those. Plus the non-text files\nbenefit you mentioned is also huge.\n\n> as I understand \"mergetool\" is handed an\n> already conflicted state and asked to resolve it, it would not be\n> possible without at least looking at the stage #1 to recover the\n> base for folks who do not use diff3 style.\n\nI feel strongly that LOCAL, REMOTE, and BASE should be left intact for\nthis reason, Also because they aid readers in understanding the\npre-conflicts versions of the file.\n\nRather mergetools (that support it) should be given the stage 1-3\nversions of the file in addition to the usual, unmodified, above three.\nThen each tool can decide whether or how to show each. Some graphical\ntools might be able to make effective use of all five (six?).\n\n(Feedback & other ideas are very welcome.)\n\n"},{"id":"412453","messageId":"5fda9b3f4979c_973f2083@natae.notmuch","threadId":"54839","inReplyTo":"xmqqa6ud2xuw.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-16T23:41:51Z","receivedAt":"2020-12-16T23:42:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > It doesn't make sense to display already-resolved conflicts in the\n> > different views of all mergetools.\n> >\n> > We already have the best version in MERGED, with annotations that can\n> > be used to extract a pruned version of LOCAL and REMOTE. If we are using\n> > the diff3 conflict-style, we can even extract BASE.\n> >\n> > Let's use these annotations instead of using the original files before\n> > the conflict resolution.\n> >\n> > TODO: There may be a better way to extract these files that doesn't rely\n> > on the user's conflict-style configuration.\n> >\n> > See Seth House's blog post [1] for the idea and the rationale.\n> >\n> > [1] https://www.eseth.org/2020/mergetools.html\n> >\n> > Cc: Seth House \n> > Signed-off-by: Felipe Contreras \n> \n> Hmph, I got what Seth showed, but I do not quite see how the ideas\n> in the post relate to what this patch does. The patch just avoids\n> grabbing the contents of each stage out to a file for three stages\n> using \"git checkout-index\" and instead does the same by munging the\n> diff3 output, which ought to have the same information at least for\n> text files, using \"sed\", or is there something I am not seeing?\n\nIt's not quite the same information.\n\nTake the following script that uses Seth's example:\n\n----------------------------------------\ncat > BASE < LOCAL < REMOTE <\nSigned-off-by: Felipe Contreras \n---\n git-mergetool.sh | 11 +++++++++++\n t/t7610-mergetool.sh | 17 +++++++++++++++++\n 2 files changed, 28 insertions(+)\n\ndiff --git a/git-mergetool.sh b/git-mergetool.sh\nindex e3f6d543fb..2f71da4574 100755\n--- a/git-mergetool.sh\n+++ b/git-mergetool.sh\n@@ -322,6 +322,17 @@ merge_file () {\n \tcheckout_staged_file 2 \"$MERGED\" \"$LOCAL\"\n \tcheckout_staged_file 3 \"$MERGED\" \"$REMOTE\"\n \n+\t# TODO Shouldn't merge-file have a --base option?\n+\tgit merge-file --diff3 -q -p \"$LOCAL\" \"$BASE\" \"$REMOTE\" |\n+\t\tsed -e '/^<<<<<<< /,/^||||||| /d' -e '/^=======$/,/^>>>>>>> /d' \\\n+\t\t\t>\"${BASE}_resolved\"\n+\tgit merge-file --ours -q -p \"$LOCAL\" \"$BASE\" \"$REMOTE\" >\"${LOCAL}_resolved\"\n+\tgit merge-file --theirs -q -p \"$LOCAL\" \"$BASE\" \"$REMOTE\" >\"${REMOTE}_resolved\"\n+\n+\tmv -f \"${BASE}_resolved\" \"$BASE\"\n+\tmv -f \"${LOCAL}_resolved\" \"$LOCAL\"\n+\tmv -f \"${REMOTE}_resolved\" \"$REMOTE\"\n+\n \tif test -z \"$local_mode\" || test -z \"$remote_mode\"\n \tthen\n \t\techo \"Deleted merge conflict for '$MERGED':\"\ndiff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh\nindex 70afdd06fa..69260c4a46 100755\n--- a/t/t7610-mergetool.sh\n+++ b/t/t7610-mergetool.sh\n@@ -828,4 +828,21 @@ test_expect_success 'mergetool -Oorder-file is honored' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'skip unnecessary chunks' '\n+\ttest_when_finished \"git reset --hard\" &&\n+\tgit checkout -b test${test_count}_b master &&\n+\techo -e \"base\\n\\na\" >file1 &&\n+\tgit commit -a -m \"base\" &&\n+\techo -e \"base\\n\\nc\" >file1 &&\n+\tgit commit -a -m \"remote update\" &&\n+\tgit checkout -b test${test_count}_a HEAD~ &&\n+\techo -e \"local\\n\\nb\" >file1 &&\n+\tgit commit -a -m \"local update\" &&\n+\ttest_must_fail git merge test${test_count}_b &&\n+\tyes \"\" | git mergetool file1 &&\n+\techo -e \"local\\n\\nc\" >expect &&\n+\ttest_cmp expect file1 &&\n+\tgit commit -m \"test resolved with mergetool\"\n+'\n+\n test_done\n-- \n2.30.0.rc0\n\n"},{"id":"412474","messageId":"xmqqr1npypr6.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"105041520.23756286.1608159189934.JavaMail.zimbra@eseth.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-17T05:18:21Z","receivedAt":"2020-12-17T05:19:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth House writes:\n\n> I wasn't aware of this plubming when I wrote the initial shell-script\n> version of the technique. This is a much better approach (even *if*\n> there's a negligible performance penalty). This nicely avoids\n> UNIX/Windows line-ending surprises, and instead leans on\n> already-configured Git defaults for those. Plus the non-text files\n> benefit you mentioned is also huge.\n>\n>> as I understand \"mergetool\" is handed an\n>> already conflicted state and asked to resolve it, it would not be\n>> possible without at least looking at the stage #1 to recover the\n>> base for folks who do not use diff3 style.\n>\n> I feel strongly that LOCAL, REMOTE, and BASE should be left intact for\n> this reason, Also because they aid readers in understanding the\n> pre-conflicts versions of the file.\n\nWell, good to see that we helped somebody who we do not see\nregularly around here. You should hang around here more often ;-)\n\n"},{"id":"412475","messageId":"xmqqmtydypp4.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fda9b3f4979c_973f2083@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-17T05:19:35Z","receivedAt":"2020-12-17T05:20:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> The implementation details of the proposed patch are not relevant at\n> this point; it was just to show an example of what Seth's diffconflicts\n> vim plugin does.\n\nSorry for commenting on the \"irrelevant\" part; as the patch was\nmarked with RFC label, I bothered to read it and tried to give\ncomments, but it wasn't clear which part was welcoming comments\nand which parts were off limits ;-)\n\n"},{"id":"412476","messageId":"5fdaef83a40ba_d0e26208f6@natae.notmuch","threadId":"54839","inReplyTo":"105041520.23756286.1608159189934.JavaMail.zimbra@eseth.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-17T05:41:23Z","receivedAt":"2020-12-17T05:42:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> I appreciate Felipe getting the discussion started.\n> \n> On Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote:\n> > If there is none, then what is the benefit of doing the same thing\n> > without running 3 checkout-index?\n> \n> I wasn't aware of this plubming when I wrote the initial shell-script\n> version of the technique. This is a much better approach (even *if*\n> there's a negligible performance penalty). This nicely avoids\n> UNIX/Windows line-ending surprises, and instead leans on\n> already-configured Git defaults for those. Plus the non-text files\n> benefit you mentioned is also huge.\n\nI think you misunderstood.\n\nThis command:\n\n git checkout-index --stage 2 --temp -- poem.txt\n\nWill give you *exactly* the same output as LOCAL.\n\nThe context is \"git mergetool\", not the mergetool itself.\n\n> > as I understand \"mergetool\" is handed an\n> > already conflicted state and asked to resolve it, it would not be\n> > possible without at least looking at the stage #1 to recover the\n> > base for folks who do not use diff3 style.\n> \n> I feel strongly that LOCAL, REMOTE, and BASE should be left intact for\n> this reason, Also because they aid readers in understanding the\n> pre-conflicts versions of the file.\n> \n> Rather mergetools (that support it) should be given the stage 1-3\n> versions of the file in addition to the usual, unmodified, above three.\n> Then each tool can decide whether or how to show each. Some graphical\n> tools might be able to make effective use of all five (six?).\n\nExcept as you stated in your blog post, not a *single* tool does this\ncorrectly using LOCAL, REMOTE, and BASE.\n\n * Araxis: a mess of changes\n * Beyond Compare: a mess of changes\n * DiffMerge: a mess of changes\n * kdiff3: a mess of changes\n * Meld: a mess of changes\n * Sublime Merge: displays unnecessary changes\n * SmartGit: ignores the other files\n * Fork: displays unnecessary changes\n * P4Merge: displays unnecessary changes\n * IntelliJ: a mess of changes\n * Tortoise Merge: uncertain\n * tkdiff: displays unnecessary changes\n * vimdiff: so, so wrong\n * vimdiff2: displays unnecessary changes\n * diffconflicts: RIGHT!\n\nSo all tools would benefit from the patch (except yours).\n\nWhich tool would be negatively affected?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412477","messageId":"5fdaeffc8b6c_d0e262088b@natae.notmuch","threadId":"54839","inReplyTo":"xmqqmtydypp4.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-17T05:43:24Z","receivedAt":"2020-12-17T05:44:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > The implementation details of the proposed patch are not relevant at\n> > this point; it was just to show an example of what Seth's diffconflicts\n> > vim plugin does.\n> \n> Sorry for commenting on the \"irrelevant\" part; as the patch was\n> marked with RFC label, I bothered to read it and tried to give\n> comments, but it wasn't clear which part was welcoming comments\n> and which parts were off limits ;-)\n\nAll parts welcomed comments.\n\nI'm just saying the idea is what's important in my opinion.\n\n-- \nFelipe Contreras\n"},{"id":"412480","messageId":"e5c73fed-b87e-2091-794e-19aced4dd25b@kdbg.org","threadId":"54839","inReplyTo":"5fdaef83a40ba_d0e26208f6@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2020-12-17T07:35:21Z","receivedAt":"2020-12-17T07:36:25Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.12.20 um 06:41 schrieb Felipe Contreras:\n> Seth House wrote:\n>> I appreciate Felipe getting the discussion started.\n>>\n>> On Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote:\n>>> If there is none, then what is the benefit of doing the same thing\n>>> without running 3 checkout-index?\n>>\n>> I wasn't aware of this plubming when I wrote the initial shell-script\n>> version of the technique. This is a much better approach (even *if*\n>> there's a negligible performance penalty). This nicely avoids\n>> UNIX/Windows line-ending surprises, and instead leans on\n>> already-configured Git defaults for those. Plus the non-text files\n>> benefit you mentioned is also huge.\n> \n> I think you misunderstood.\n> \n> This command:\n> \n> git checkout-index --stage 2 --temp -- poem.txt\n> \n> Will give you *exactly* the same output as LOCAL.\n> \n> The context is \"git mergetool\", not the mergetool itself.\n> \n>>> as I understand \"mergetool\" is handed an\n>>> already conflicted state and asked to resolve it, it would not be\n>>> possible without at least looking at the stage #1 to recover the\n>>> base for folks who do not use diff3 style.\n>>\n>> I feel strongly that LOCAL, REMOTE, and BASE should be left intact for\n>> this reason, Also because they aid readers in understanding the\n>> pre-conflicts versions of the file.\n>>\n>> Rather mergetools (that support it) should be given the stage 1-3\n>> versions of the file in addition to the usual, unmodified, above three.\n>> Then each tool can decide whether or how to show each. Some graphical\n>> tools might be able to make effective use of all five (six?).\n> \n> Except as you stated in your blog post, not a *single* tool does this\n> correctly using LOCAL, REMOTE, and BASE.\n> \n> * Araxis: a mess of changes\n> * Beyond Compare: a mess of changes\n> * DiffMerge: a mess of changes\n> * kdiff3: a mess of changes\n> * Meld: a mess of changes\n> * Sublime Merge: displays unnecessary changes\n> * SmartGit: ignores the other files\n> * Fork: displays unnecessary changes\n> * P4Merge: displays unnecessary changes\n> * IntelliJ: a mess of changes\n> * Tortoise Merge: uncertain\n> * tkdiff: displays unnecessary changes\n> * vimdiff: so, so wrong\n> * vimdiff2: displays unnecessary changes\n> * diffconflicts: RIGHT!\n> \n> So all tools would benefit from the patch (except yours).\n> \n> Which tool would be negatively affected?\n\nWhere's WinMerge in your list? I'm mostly using WinMerge these days, and\nit can do what your patch does all by itself. It does not require the\nproposed post-processing of stages in order to show only the real\nconflicts. I would say that this is a hint that post-processing should\nbe moved to the tool drivers, and should not be done at the proposed level.\n\nI don't know, though, whether your patch would have a negative effect\nfor WinMerge.\n\n-- Hannes\n"},{"id":"412482","messageId":"5fdb1687825e9_d35b620855@natae.notmuch","threadId":"54839","inReplyTo":"e5c73fed-b87e-2091-794e-19aced4dd25b@kdbg.org","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-17T08:27:51Z","receivedAt":"2020-12-17T08:28:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johannes Sixt wrote:\n> Am 17.12.20 um 06:41 schrieb Felipe Contreras:\n> > Seth House wrote:\n> >> I appreciate Felipe getting the discussion started.\n> >>\n> >> On Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote:\n> >>> If there is none, then what is the benefit of doing the same thing\n> >>> without running 3 checkout-index?\n> >>\n> >> I wasn't aware of this plubming when I wrote the initial shell-script\n> >> version of the technique. This is a much better approach (even *if*\n> >> there's a negligible performance penalty). This nicely avoids\n> >> UNIX/Windows line-ending surprises, and instead leans on\n> >> already-configured Git defaults for those. Plus the non-text files\n> >> benefit you mentioned is also huge.\n> > \n> > I think you misunderstood.\n> > \n> > This command:\n> > \n> > git checkout-index --stage 2 --temp -- poem.txt\n> > \n> > Will give you *exactly* the same output as LOCAL.\n> > \n> > The context is \"git mergetool\", not the mergetool itself.\n> > \n> >>> as I understand \"mergetool\" is handed an\n> >>> already conflicted state and asked to resolve it, it would not be\n> >>> possible without at least looking at the stage #1 to recover the\n> >>> base for folks who do not use diff3 style.\n> >>\n> >> I feel strongly that LOCAL, REMOTE, and BASE should be left intact for\n> >> this reason, Also because they aid readers in understanding the\n> >> pre-conflicts versions of the file.\n> >>\n> >> Rather mergetools (that support it) should be given the stage 1-3\n> >> versions of the file in addition to the usual, unmodified, above three.\n> >> Then each tool can decide whether or how to show each. Some graphical\n> >> tools might be able to make effective use of all five (six?).\n> > \n> > Except as you stated in your blog post, not a *single* tool does this\n> > correctly using LOCAL, REMOTE, and BASE.\n> > \n> > * Araxis: a mess of changes\n> > * Beyond Compare: a mess of changes\n> > * DiffMerge: a mess of changes\n> > * kdiff3: a mess of changes\n> > * Meld: a mess of changes\n> > * Sublime Merge: displays unnecessary changes\n> > * SmartGit: ignores the other files\n> > * Fork: displays unnecessary changes\n> > * P4Merge: displays unnecessary changes\n> > * IntelliJ: a mess of changes\n> > * Tortoise Merge: uncertain\n> > * tkdiff: displays unnecessary changes\n> > * vimdiff: so, so wrong\n> > * vimdiff2: displays unnecessary changes\n> > * diffconflicts: RIGHT!\n> > \n> > So all tools would benefit from the patch (except yours).\n> > \n> > Which tool would be negatively affected?\n> \n> Where's WinMerge in your list?\n\nIt's not my list; it's Seth's list.\n\n> I'm mostly using WinMerge these days, and it can do what your patch\n> does all by itself.\n\nReally? Because under Wine it doesn't look like it:\n\n 1. Before: https://snipboard.io/8JA5Oz.jpg\n 2. After: https://snipboard.io/HUXnOg.jpg\n\n> I don't know, though, whether your patch would have a negative effect\n> for WinMerge.\n\nSeems like it has a *positive* effect. Like in all mergetools.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412485","messageId":"20201217094424.GA75257@ellen","threadId":"54839","inReplyTo":"e5c73fed-b87e-2091-794e-19aced4dd25b@kdbg.org","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-17T09:44:24Z","receivedAt":"2020-12-17T09:45:27Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Thu, Dec 17, 2020 at 08:35:21AM +0100, Johannes Sixt wrote:\n> Where's WinMerge in your list?\n\nAdded. Thanks for the suggestion; I wasn't familiar with it. Let me know\nif I missed anything in my (quick) assessment. The \"auto-merge\" function\ndoes indeed produce similar results to Felipe's patch.\n\n> I would say that this is a hint that post-processing should\n> be moved to the tool drivers, and should not be done at the proposed level.\n\nThat was my thought as well and it didn't occur to me to raise\na discussion here. However Felipe made the good point that adding this\nfunctionality in upstream Git would have immediate downstream effects\nfor most tools. Almost every mergetool I've surveyed so far simply\nblindly shows a diff betweeen LOCAL and REMOTE (and sometimes BASE and\nsometimes MERGED) and Felipe's patch would have an immediate benefit for\nall those tools.\n\nThere are a few notable exceptions that have their own, internal\nconflict resolution logic -- tkdiff, WinMerge, and (I think) IntelliJ.\nAnd only two tools make direct use of the conflict resolution that Git\nalready performed to produce MERGED -- Emacs+Magit, and diffconflicts.\nThose tools would have to make a decision whether to opt-in to the\nautoMerge flag or not.\n\nI did not initially like Felipe's patch because I personally want my\nmergetool to use all five of LOCAL, REMOTE, BASE, _and_ the two split\nhalves of MERGED. However the pragmatism of it is growing on me. Because\nso many mergetools do simply diff LOCAL and REMOTE this one, simple\nopt-in would positively benefit all of them.\n\n"},{"id":"412487","messageId":"5fdb3471c6bb7_d6d032087@natae.notmuch","threadId":"54839","inReplyTo":"20201217094424.GA75257@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-17T10:35:29Z","receivedAt":"2020-12-17T10:36:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Thu, Dec 17, 2020 at 08:35:21AM +0100, Johannes Sixt wrote:\n> > Where's WinMerge in your list?\n> \n> Added. Thanks for the suggestion; I wasn't familiar with it. Let me know\n> if I missed anything in my (quick) assessment. The \"auto-merge\" function\n> does indeed produce similar results to Felipe's patch.\n> \n> > I would say that this is a hint that post-processing should\n> > be moved to the tool drivers, and should not be done at the proposed level.\n> \n> That was my thought as well and it didn't occur to me to raise\n> a discussion here. However Felipe made the good point that adding this\n> functionality in upstream Git would have immediate downstream effects\n> for most tools. Almost every mergetool I've surveyed so far simply\n> blindly shows a diff betweeen LOCAL and REMOTE (and sometimes BASE and\n> sometimes MERGED) and Felipe's patch would have an immediate benefit for\n> all those tools.\n> \n> There are a few notable exceptions that have their own, internal\n> conflict resolution logic -- tkdiff, WinMerge, and (I think) IntelliJ.\n> And only two tools make direct use of the conflict resolution that Git\n> already performed to produce MERGED -- Emacs+Magit, and diffconflicts.\n> Those tools would have to make a decision whether to opt-in to the\n> autoMerge flag or not.\n\nEach tool would have to be evaluated individually, but at least from\nwhat I can see your tool--diffconflicts--shows exactly the same diff\nwith or without my patch, and the `mergetool.automerge` configuration.\nIt's only the DiffConflictsShowHistory command (which is secondary\nfunctionality, that you didn't even mention in your blog) that gets\naffected.\n\nSo, yes; *some* behavior is affected, but in my opinion not in a\nnegative way.\n\nIn my view the whole point of \"git mergetool\" is to resolve conflicts,\nso if git can resolve conflicts *before* launching the mergetool, it\nshould (whether it's rerere or automerge).\n\n> I did not initially like Felipe's patch because I personally want my\n> mergetool to use all five of LOCAL, REMOTE, BASE, _and_ the two split\n> halves of MERGED. However the pragmatism of it is growing on me. Because\n> so many mergetools do simply diff LOCAL and REMOTE this one, simple\n> opt-in would positively benefit all of them.\n\nYes. But other people may want to see the secondary functionality of\nyour DiffConflictsShowHistory command with simplified conflicts, and\nthose people can enable the option.\n\nIf you want to see the original LOCAL, REMOTE, and BASE, you can turn\noff that option (or simply never turn it on).\n\nWith the option everyone can have what they want.\n\nI for example can keep using `gvimdiff3`, except with simpler diff\nchunks, thanks to your idea.\n\nAnd for the record; \"git mergetool\" is one of of those things that you\nsetup once, and forget about it. My fingers have been trained for more\nthan a decade (maybe two) on exactly the same configuration, and I\ninitially didn't think you were onto something.\n\nIt's really good that you did setup a test repository with a merge\nconflict that showcased the different situations one might encounter. It\nimmediately became clear to me that you were indeed onto something.\n\nSo I give you full credit for the idea, and explaining it succinctly,\nthat's in the commit message. I just found a way to shove it directly\ninto \"git mergetool\".\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412492","messageId":"20201217175037.GA80608@ellen","threadId":"54839","inReplyTo":"5fdb3471c6bb7_d6d032087@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-17T17:50:37Z","receivedAt":"2020-12-17T17:51:25Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Thu, Dec 17, 2020 at 04:35:29AM -0600, Felipe Contreras wrote:\n> If you want to see the original LOCAL, REMOTE, and BASE, you can turn\n> off that option (or simply never turn it on).\n\nAgreed.\n\nFelipe, the functionality in the v3 version of your patch looks good to\nme and I think it's well worth including in upstream Git.\n\nWould you mind switching the autoMerge option to be per-tool rather than\nunder the main mergetool config section?\n\nYou're right that it will likely not cause any downstream errors; it's\njust a difference in preference. The tools that perform their own\nconflict resolution will likely want it off and most of the other tools\nwill likely want it on. I could envision wanting to configure multiple\nmergetools -- some with and some without.\n\nAfter work today I can go back through the list of mergetools reviewed\nin my post and grab screenshots of each with this option enabled so that\neveryone in this thread can quickly compare the before/after results.\n\n"},{"id":"412497","messageId":"deb42d8a-1ac6-7100-eba9-d75f7c8ba0d8@kdbg.org","threadId":"54839","inReplyTo":"5fdb1687825e9_d35b620855@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2020-12-17T19:23:11Z","receivedAt":"2020-12-17T19:24:08Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.12.20 um 09:27 schrieb Felipe Contreras:\n> Johannes Sixt wrote:\n>> I'm mostly using WinMerge these days, and it can do what your patch\n>> does all by itself.\n> \n> Really? Because under Wine it doesn't look like it:\n> \n> 1. Before: https://snipboard.io/8JA5Oz.jpg\n> 2. After: https://snipboard.io/HUXnOg.jpg\n\nThese show 3 panes, while mine shows only 2. And I think I know why:\n\nFirst, I seem to use an older version of WinMerge that does not support\n3-way diffs.\n\nSecond, I only run the merge tool via Git GUI, and it has its own tool\ndrivers and completely bypasses git-mergetool. In particular, it invokes\nWinMerge in a way that it auto-merges the non-conflicted parts, whereas\n(the unpatched) git-mergetool does it differently such that it shows\nmany more differences in the same merge situation.\n\n-- Hannes\n"},{"id":"412498","messageId":"xmqq5z50z0yu.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"20201217175037.GA80608@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-17T19:28:25Z","receivedAt":"2020-12-17T19:29:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth House writes:\n\n> Would you mind switching the autoMerge option to be per-tool rather than\n> under the main mergetool config section?\n>\n> You're right that it will likely not cause any downstream errors; it's\n> just a difference in preference. The tools that perform their own\n> conflict resolution will likely want it off and most of the other tools\n> will likely want it on. I could envision wanting to configure multiple\n> mergetools -- some with and some without.\n\nThanks for a concise summary.\n\nMany people may stick to just a single tool and may find a single\nmergetool.autoMerge knob convenient (and it is OK for them if the\nnew behaviour broke a tool they do not use), but for those who use\nmore than one, being able to configure them differently would be\nvaluable. So I agree that making it a per-tool option would be a\ngood thing to do. Extra bonus for \"this covers all\" fallback default\nperhaps like so:\n\n\tif test \"$(git config --get --bool \"mergetool.$merge_tool.automerge\" ||\n\t git config --get --bool \"mergetool.autoMerge\" ||\n\t echo true)\" = true\n\tthen\n\t\t... do the new \"reduce conflicts\" thing ...\n\telse\n\t\t... do the \"grab the original\" thing ...\n\tfi\n\nThere is another thing that the final version may want to consider.\n\nWould there be a reason for a tool to actively want to refuse the\nend-user request to use the new autoMerge behaviour? A tool that\ncan merge binary files may want to make sure it gets the original\nthree blobs that got involved in the conflict, and the above\nwould allow users to break such a tool. We could say \"don't do\nthat then\" to users, or we can use the same mechanism to set up\ndiff_cmd() etc. per tool [*1*]. A tool that always wants to use\nthe autoMerge without letting end-user to opt out can be handled\nwith the same mechanism, but I think that is less likely.\n\nAlso, just for completeness (this is a comment made after seeing v3),\nunlike the previous rounds, we do not have to worry about conflict\nmarker length attribute user may have and rely on the default\nmarker-size hardcoded at the xdl_merge() layer. If we wanted to\nmake it even safer, \"git merge-file --diff3\" invocation can also\nuse a hardcoded --marker-size=7 option to protect from changes in\nthe underlying xdl_merge()'s default.\n\nUnfortunately, it however also means that we can be confused when we\nare seeing a conflicted outer merge of a recursive merge. In such a\ncase, the virtual ancestor version in stage #1 can have conflict\nmarkers from the inner merge that also conflicted, which uses marker\nsize a bit longer than what the user gave via the attribute\nmachinery. If that \"a bit longer\" length happens to be the same as\nthe hardcoded assumption of 7 the sed script in v3 makes, the sed\nscript would not be able to tell between the existing markers in the\nvirtual ancestor version and the markers \"git merge-file --diff3\"\ncreates.\n\nIt is unlikely that the end-user sets conflict marker length to\nanything shorter than the default 7, so I think it is OK to punt\nthis potential problem, and assume we are OK. The limitation may\nneed to be documented, though.\n\n> After work today I can go back through the list of mergetools reviewed\n> in my post and grab screenshots of each with this option enabled so that\n> everyone in this thread can quickly compare the before/after results.\n\nThanks.\n\n\n[Footnote]\n\n*1* If we were to go that extra mile for completeness, the result\n would roughly look like the following outline:\n\n 1. git-mergetool--lib.sh::setup_tool() would define a new helper\n function \n\n\tautomerge_enabled () {\n\t\ttrue\n\t}\n\n to be used as the fallback\n\n 2. a tool that wants to use the original without allowing the user\n to opt into automerge would add\n\n\tautomerge_enabled () {\n\t\tfalse\n\t}\n\n in mergetools/$toolname (where toolname is like 'tkdiff',\n 'vimdiff', etc.)\n\n 3. then the \"consult mergetool..automerge and then\n mergetool.automerge in this order\" if statement we saw above\n would first ask the new helper function, i.e.\n\n\tif automerge_enabled &&\n\t test \"$(git config --get --bool \"mergetool.$merge_tool.automerge\" ||\n git config --get --bool \"mergetool.automerge\" ||\n\t echo true)\" = true\n\tthen\n\t\t...\n\n"},{"id":"412510","messageId":"5fdc0e6dd79a7_f2faf208a1@natae.notmuch","threadId":"54839","inReplyTo":"20201217175037.GA80608@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T02:05:33Z","receivedAt":"2020-12-18T02:06:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Thu, Dec 17, 2020 at 04:35:29AM -0600, Felipe Contreras wrote:\n> > If you want to see the original LOCAL, REMOTE, and BASE, you can turn\n> > off that option (or simply never turn it on).\n> \n> Agreed.\n> \n> Felipe, the functionality in the v3 version of your patch looks good to\n> me and I think it's well worth including in upstream Git.\n> \n> Would you mind switching the autoMerge option to be per-tool rather than\n> under the main mergetool config section?\n\nAs I said; I don't see the point.\n\nEven if I were using diffconflict, I would want this option on.\n\nSo it's not a tool configuration; it's a user preference.\n\n> You're right that it will likely not cause any downstream errors; it's\n> just a difference in preference. The tools that perform their own\n> conflict resolution will likely want it off\n\nWhat tools would that be?\n\n-- \nFelipe Contreras\n"},{"id":"412512","messageId":"5fdc1436b6e44_f2faf2084f@natae.notmuch","threadId":"54839","inReplyTo":"deb42d8a-1ac6-7100-eba9-d75f7c8ba0d8@kdbg.org","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T02:30:14Z","receivedAt":"2020-12-18T02:31:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johannes Sixt wrote:\n> Am 17.12.20 um 09:27 schrieb Felipe Contreras:\n> > Johannes Sixt wrote:\n> >> I'm mostly using WinMerge these days, and it can do what your patch\n> >> does all by itself.\n> > \n> > Really? Because under Wine it doesn't look like it:\n> > \n> > 1. Before: https://snipboard.io/8JA5Oz.jpg\n> > 2. After: https://snipboard.io/HUXnOg.jpg\n> \n> These show 3 panes, while mine shows only 2. And I think I know why:\n> \n> First, I seem to use an older version of WinMerge that does not support\n> 3-way diffs.\n> \n> Second, I only run the merge tool via Git GUI, and it has its own tool\n> drivers and completely bypasses git-mergetool. In particular, it invokes\n> WinMerge in a way that it auto-merges the non-conflicted parts, whereas\n> (the unpatched) git-mergetool does it differently such that it shows\n> many more differences in the same merge situation.\n\nSo it makes sense that the users of \"git mergetool\" get the same\nbenefits of the users of git-gui (with the proposed patch).\n\nHowever, I'm trying to parse what git-gui is doing in\ngit-gui/lib/mergetool.tcl, and I see nothing similar to automerging.\n\nPlus, the arguments passed to the tool are completely different:\n\n \"$merge_tool_path\" -e -ub -wl \\\n -dl \"Theirs File\" -dr \"Mine File\" \"$REMOTE\" \"$LOCAL\" \"$MERGED\"]\n\n\t\"$merge_tool_path\" -u -e -dl Local -dr Remote \\\n\t\t\"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n\nIt's not even gramatically correct.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412514","messageId":"5fdc153b97837_f2faf208ce@natae.notmuch","threadId":"54839","inReplyTo":"xmqq5z50z0yu.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T02:34:35Z","receivedAt":"2020-12-18T02:35:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Seth House writes:\n> \n> > Would you mind switching the autoMerge option to be per-tool rather than\n> > under the main mergetool config section?\n> >\n> > You're right that it will likely not cause any downstream errors; it's\n> > just a difference in preference. The tools that perform their own\n> > conflict resolution will likely want it off and most of the other tools\n> > will likely want it on. I could envision wanting to configure multiple\n> > mergetools -- some with and some without.\n> \n> Thanks for a concise summary.\n> \n> Many people may stick to just a single tool and may find a single\n> mergetool.autoMerge knob convenient (and it is OK for them if the\n> new behaviour broke a tool they do not use), but for those who use\n> more than one, being able to configure them differently would be\n> valuable.\n\nOn what tool would you turn this on, and what tool would you turn this\noff?\n\n-- \nFelipe Contreras\n"},{"id":"412515","messageId":"20201218023534.GA117762@ellen","threadId":"54839","inReplyTo":"5fdc0e6dd79a7_f2faf208a1@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-18T02:35:34Z","receivedAt":"2020-12-18T02:36:37Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Thu, Dec 17, 2020 at 08:05:33PM -0600, Felipe Contreras wrote:\n> > Would you mind switching the autoMerge option to be per-tool rather than\n> > under the main mergetool config section?\n> \n> As I said; I don't see the point.\n\nI know you've said that. But I would prefer that, and Junio requested\nthat, and other people may prefer that as well. Since it's not too much\ntrouble to make the option per-tool with a global fallback, and since\nJunio already provided example code to do that, do you mind adding it\nanyway even though you don't see the point?\n\n"},{"id":"412517","messageId":"5fdc18a91c402_f2faf20837@natae.notmuch","threadId":"54839","inReplyTo":"20201218023534.GA117762@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T02:49:13Z","receivedAt":"2020-12-18T02:50:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Thu, Dec 17, 2020 at 08:05:33PM -0600, Felipe Contreras wrote:\n> > > Would you mind switching the autoMerge option to be per-tool rather than\n> > > under the main mergetool config section?\n> > \n> > As I said; I don't see the point.\n> \n> I know you've said that. But I would prefer that, and Junio requested\n> that, and other people may prefer that as well. Since it's not too much\n> trouble to make the option per-tool with a global fallback, and since\n> Junio already provided example code to do that, do you mind adding it\n> anyway even though you don't see the point?\n\nIt's not about the level of effort; it's about doing what makes sense.\n\nAnd no person is the sole arbiter of truth, in this list, or anywhere.\nPeople have managed to change Junio's mind.\n\nYou said you would provide a list of tools that would be affected. Do you\nhave the list of tools who would want this flag off regardless of user\npreference?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412522","messageId":"20201218054947.GA123376@ellen","threadId":"54839","inReplyTo":"5fdc18a91c402_f2faf20837@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-18T05:49:47Z","receivedAt":"2020-12-18T05:50:51Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote:\n> And no person is the sole arbiter of truth, in this list, or anywhere.\n> People have managed to change Junio's mind.\n\nI'm not worried about Junio but I am wondering if anyone has managed to\nchange your mind. You and I have been going back and forth on this list\nand on Reddit for two solid days and, to be frank, I'm running out of\nsteam.\n\n> You said you would provide a list of tools that would be affected.\n\nNo, I said I would provide a list of before/after screenshots so people\nin this thread that haven't been following the entire discussion can\nmore easily see the differences and benefits of this change.\n\nI can't speak for the preferences of all the mergetool authors out there\nbut I will try to convince you of the merit of adding a configuration\nflag in two places instead of just one. This took me a long time to\nwrite; I would appreciate it if you read it slowly and carefully.\n\nThere are three broad classifications of mergetools that I've seen so\nfar. I've only collected notes for seventeen of them but there are many,\nmany others. I mentioned those classifications earlier in this thread\nbut to repeat them here:\n\n1. Tools that ignore conflict resolution and simply diff LOCAL and\n REMOTE. This accounts for most of them.\n2. Tools that perform their own, internal conflict resolution. Examples\n are tkdiff, WinMerge, IntelliJ.\n3. Tools that reuse Git's conflict resolution by splitting MERGED.\n Examples are Emacs + Magit, vim-mergetool, diffconflicts.\n\nThis patch *will* (probably) always benefit the first group. Because\nthis patch *overwrites* LOCAL and REMOTE those tools will see immediate\nbenefit without having to make any changes at all.\n\nThis patch *may* benefit the second group, or it may not affect them at\nall, or they may want it off. If they keep it on they will run conflict\nresolution against files that have already undergone that process in Git\nand likely turn up no additional resolutions since Git is quite good at\ndoing that. It is also possible that some of them may do a better job\nthan Git, or that some of them may want Git to tackle some of the\nconflict resolution (things that require access to the file history such\nas renames or recursive parents), but also want to perform even more\nsophisticated conflict resolution on top of that. Some of those tools\nare very clever and innovation in this space is still happening.\n\nThis patch *may* benefit the third group or it may make them no longer\nnecessary. Speaking as the author of one of them: I see that as a good\nthing.\n\nThis patch *may* prevent tools in the second and third groups from\nhaving all the information they desire to show users without also\nrunning additional Git commands. Because this patch *overwrites* LOCAL\nand REMOTE any tool that wishes to show the state of the file before the\nmerge was started will need to use Git to generate a new copy of those\nfiles. Although this is a negative I think benefiting the large number\nof tools in the first group outweighs this negative. Because the second\nand third groups of tools are more sophisticated, I think the authors of\nthose tools are better suited to navigating these pros and cons.\n\nIn closing, below are several use-cases for having both a tool-level\nflag and a global flag:\n\nI, as the author of diffconflicts, *will* want to disable this flag for\ndiffconflicts because that tool already does what this flag does *and*\nbecause that tool makes use of the original versions of LOCAL and\nREMOTE which this patch destroys.\n\nI, as a user of diffconflicts, *may* want to disable this flag because\nin practice I don't actually reference LOCAL and REMOTE very often.\nOther users may reference LOCAL and REMOTE every time. You yourself\nsaid, \"Even if I were using diffconflict, I would want this option on.\"\nOther users may choose differently than you because you are also not the\n\"sole arbiter of truth\" and because this is entirely about personal\npreference and is decidedly not about objective truth. If this patch\nalways benefited everyone then we would make it default and not put it\nbehind an opt-in flag.\n\nI, as a user of diffconflicts, may want to both disable this flag for\ndiffconflicts but enable this flag for VS Code and kdiff3. It is not\nunusual for people to use more than one mergetool. Some of them are\nbetter or worse at visualizing different kinds of conflicts. Sometimes\na conflict is small and straightforward; othertimes a conflict is\ncomplicated and requires deep knowledge of the history of both branches.\nIf we force this to be a global flag only then users will not be able to\nmake different choices for different tools.\n\nSomeone who does use multiple mergetools but only uses tools from group\none may appreciate a single global flag so s/he doesn't need to set it\nfor each tool.\n\nSomeone who is actively developing a new mergetool may want to enable or\ndisable this flag for that tool while still keeping the flag enabled or\ndisabled for tools that s/he uses for work or school. Someone who is\ncomparing and contrasting multiple mergetools for work or school may\nwant to selectively enable or disable the flag for one tool or another\nin order to do the comparison. Someone may want the same mergetool\nconfigured twice, once with this flag and once without, in order to\ncontrast the difference.\n\nAn end-user may want to use a mergetool differently than the author\nintended. You said, \"This should be a setting in the tool driver, not\na user-visible setting,\" and then you said, \"Even if I were using\ndiffconflict, I would want this option on.\" But I said, \"I, as the\nauthor of diffconflicts, *will* want to disable this flag.\" and there's\nno reason we can't have both. I can't presume what preference other\nmergetool authors will have. We can make some educated guesses and even\ndefault the option to true for some mergetool wrappers that ship with\nGit but there's every possibility that a user will prefer it a different\nway or that a mergetool author will. And there's every possibility that\nthere will be differing opinions between users and authors like there is\nbetween you and me. But that's ok! Because it's just a configuration\noption.\n\n"},{"id":"412546","messageId":"5fdc7a7d3a933_f4673208d0@natae.notmuch","threadId":"54839","inReplyTo":"20201218054947.GA123376@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T09:46:37Z","receivedAt":"2020-12-18T09:47:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote:\n> > And no person is the sole arbiter of truth, in this list, or anywhere.\n> > People have managed to change Junio's mind.\n> \n> I'm not worried about Junio but I am wondering if anyone has managed to\n> change your mind.\n\nYes, with evidence and reasoning.\n\n> You and I have been going back and forth on this list\n> and on Reddit for two solid days and, to be frank, I'm running out of\n> steam.\n\nThat doesn't mean you are right.\n\n> > You said you would provide a list of tools that would be affected.\n> \n> No, I said I would provide a list of before/after screenshots so people\n> in this thread that haven't been following the entire discussion can\n> more easily see the differences and benefits of this change.\n\nWe can run the simulation in our mind; if uncontested chunks are the\nsame in all files, then *all* tools would present them with no diff.\n\nNo tool would present a diff in the second paragraph. We don't need to\nsee the screenshots to know that.\n\nI don't see how that effort advances this discussion, at this point\nnobody is against this change. The discussion now is about what kind of\nconfiguration it should be: user or tool.\n\n> I can't speak for the preferences of all the mergetool authors out there\n> but I will try to convince you of the merit of adding a configuration\n> flag in two places instead of just one.\n\nThe preferences of mergetool authors do not matter, what matters is how\nthe users of those tools use them.\n\nWe don't need to hear from the author of WinMerge, we need to hear from\nJohannes, who uses WinMerge.\n\nAuthors are fallible--like everyone else--and they can be wrong about\ntheir own inventions. Play-Doh for example was invented to remove\nwallpapers.\n\nIt's perfectly fine for a user to use a tool in ways the author did not\nintend.\n\n> This took me a long time to write; I would appreciate it if you read\n> it slowly and carefully.\n\nSure.\n\n> There are three broad classifications of mergetools that I've seen so\n> far. I've only collected notes for seventeen of them but there are many,\n> many others. I mentioned those classifications earlier in this thread\n> but to repeat them here:\n> \n> 1. Tools that ignore conflict resolution and simply diff LOCAL and\n> REMOTE. This accounts for most of them.\n\nThis is not true.\n\nI already told you this, but *all* tools have MERGED in one of their\npanes.\n\nIf a tool doesn't have MERGED, then it can't work.\n\n> 2. Tools that perform their own, internal conflict resolution. Examples\n> are tkdiff, WinMerge, IntelliJ.\n\nOK. I don't see how that is relevant.\n\n> 3. Tools that reuse Git's conflict resolution by splitting MERGED.\n> Examples are Emacs + Magit, vim-mergetool, diffconflicts.\n\nInteresting. I know 2/3 of the people that are the original authors of\nthese tools; I know Marius Vollmer (the original author of magit).\n\nHowever, I don't think magit is a mergetool; you can't do \"git mergetool\n-t magit\".\n\n> This patch *will* (probably) always benefit the first group. Because\n> this patch *overwrites* LOCAL and REMOTE those tools will see immediate\n> benefit without having to make any changes at all.\n\nYes.\n\n> This patch *may* benefit the second group, or it may not affect them at\n> all, or they may want it off.\n\nWhy might they want it off? Let's read...\n\n> If they keep it on they will run conflict resolution against files\n> that have already undergone that process in Git and likely turn up no\n> additional resolutions since Git is quite good at doing that. It is\n> also possible that some of them may do a better job than Git, or that\n> some of them may want Git to tackle some of the conflict resolution\n> (things that require access to the file history such as renames or\n> recursive parents), but also want to perform even more sophisticated\n> conflict resolution on top of that. Some of those tools are very\n> clever and innovation in this space is still happening.\n\nYou did not explain why they would want it off.\n\nIn your mergetool rant [2] you wrote this point:\n\n 4. All conflicts in the second stanza were automatically resolved. They\n should not be shown to the user.\n\nSo it doesn't matter if git does it, or the mergetool does it, you said\nthe conflicts in the second paragraph can be solved, so they should not\nbe shown to the user.\n\nIf git does it, that's one less thing the mergetool has to do.\n\nEven if the mergetool is smarter than git, in fact, so smart it's run by\na superintelligent AI; it still would resolve the conflict in precisely\nthe same way as git, and it still should not present that conflict to\nthe user.\n\nSo the end result is the same. Correct?\n\n> This patch *may* benefit the third group or it may make them no longer\n> necessary. Speaking as the author of one of them: I see that as a good\n> thing.\n\nYes, at least the core of what they do.\n\n> This patch *may* prevent tools in the second and third groups from\n> having all the information they desire to show users without also\n> running additional Git commands.\n\nExplain how.\n\n-------------------------------------------------\ncat > BASE < LOCAL < REMOTE < REMOTE <>>>>>> REMOTE\n\nsentence.\n-------------------------------------------------\n\nIf there was no conflict in the first paragraph git wouldn't have\nbothered the user with the second paragraph.\n\nWhy should the mergetool?\n\n> Because this patch *overwrites* LOCAL and REMOTE any tool that wishes\n> to show the state of the file before the merge was started will need\n> to use Git to generate a new copy of those files.\n\nWhy would they want to do that? Git already has determined there's no\nvaluable information there.\n\n> Although this is a negative I think benefiting the large number of\n> tools in the first group outweighs this negative. Because the second\n> and third groups of tools are more sophisticated, I think the authors\n> of those tools are better suited to navigating these pros and cons.\n\nI'm sorry, but you still haven't determined that it's a negative, and\nwhy.\n\n> In closing, below are several use-cases for having both a tool-level\n> flag and a global flag:\n> \n> I, as the author of diffconflicts, *will* want to disable this flag for\n> diffconflicts because that tool already does what this flag does *and*\n> because that tool makes use of the original versions of LOCAL and\n> REMOTE which this patch destroys.\n\nYes, but the author of diffconflicts is not infallible.\n\nExplain why the *users* of the diffconclits tool would be affected\nnegatively by not being shown a conflict that git resolved\nautomatically, and if it were not for other *real* conflicts in the file\nwouldn't have bothered to stop the merge.\n\nFurthermore, explain why a user in vimdiff2 wouldn't want to see the\ntrivial conflict, but a user in diffconflicts would.\n\n> I, as a user of diffconflicts, *may* want to disable this flag because\n> in practice I don't actually reference LOCAL and REMOTE very often.\n\nIt doesn't change your experience at all.\n\n> Other users may reference LOCAL and REMOTE every time.\n\nYes, and they would prefer the trivial conflicts that git already\nresolved *not there*.\n\n> You yourself said, \"Even if I were using diffconflict, I would want\n> this option on.\" Other users may choose differently than you because\n> you are also not the \"sole arbiter of truth\" and because this is\n> entirely about personal preference and is decidedly not about\n> objective truth.\n\nAnd that's why it is an *OPTION*.\n\nDidn't I introduce an option for those other users?\n\n> If this patch always benefited everyone then we would make it default\n> and not put it behind an opt-in flag.\n\nThat's not how git works.\n\n10 years ago doing \"git merge\" (without arguments) used to fail, then\nafter I suggested a sensible default, the merge.defaultToUpstream option\nwas introduced, and turned off by default, even though it was clear 100%\nof users would want this.\n\n3 years after the introduction of that flag it was turned on, and\nliterally not one person complained.\n\nToday you can't find a single person that has\n\"merge.defaulttoupstream=false\" in their configuration, and yet, the\noption is still there.\n\nIn git even if 100% of users we know would benefit, as long as there\nexists one hypothetical user that might not, the option is there.\n\n> I, as a user of diffconflicts, may want to both disable this flag for\n> diffconflicts but enable this flag for VS Code and kdiff3.\n\nWhy? You still have not explained.\n\n> It is not unusual for people to use more than one mergetool. Some of\n> them are better or worse at visualizing different kinds of conflicts.\n> Sometimes a conflict is small and straightforward; othertimes a\n> conflict is complicated and requires deep knowledge of the history of\n> both branches. If we force this to be a global flag only then users\n> will not be able to make different choices for different tools.\n\nThey would still not be able to make different choices.\n\nIf you read Junio's proposal, if kdiff3 returns false in\nautomerge_enabled, then the user can *not* turn this on.\n\n> Someone who does use multiple mergetools but only uses tools from group\n> one may appreciate a single global flag so s/he doesn't need to set it\n> for each tool.\n\nYou still have not explained why a user might want different\nconfiguration per tool.\n\n> Someone who is actively developing a new mergetool may want to enable or\n> disable this flag for that tool while still keeping the flag enabled or\n> disabled for tools that s/he uses for work or school. Someone who is\n> comparing and contrasting multiple mergetools for work or school may\n> want to selectively enable or disable the flag for one tool or another\n> in order to do the comparison. Someone may want the same mergetool\n> configured twice, once with this flag and once without, in order to\n> contrast the difference.\n\nYes, I've been doing precisely that without problems.\n\n> An end-user may want to use a mergetool differently than the author\n> intended. You said, \"This should be a setting in the tool driver, not\n> a user-visible setting,\"\n\nThat was Johannes Sixt, not me.\n\n> and then you said, \"Even if I were using diffconflict, I would want\n> this option on.\" But I said, \"I, as the author of diffconflicts,\n> *will* want to disable this flag.\" and there's no reason we can't have\n> both.\n\nIn Junio's proposal if the author of diffconflicts disables the flag, the\nuser cannot activate it.\n\nBut even if the user could, there's no reason not to do X is not a valid\nargument in favor of doing X.\n\nYou still need a valid reason to have both.\n\n> I can't presume what preference other mergetool authors will have.\n\nAs I said; this is not relevant.\n\nWhy would a *user* of diffconflict want this off?\n\nYou still haven't given a reason.\n\n> We can make some educated guesses and even default the option to true\n> for some mergetool wrappers that ship with Git but there's every\n> possibility that a user will prefer it a different way or that a\n> mergetool author will. And there's every possibility that there will\n> be differing opinions between users and authors like there is between\n> you and me. But that's ok! Because it's just a configuration option.\n\nAt the end of the day it's not opinions that matter, it's facts.\n\n\nYou asked me to read slow and carefully a long explanation, which I did.\nNow allow me to ask something of you. Please answer the following question.\n\nDo you have any concrete evidence of a single instance where the user\nwill be negatively affected by turning on this flag in one mergetool,\nbut not so in another mergetool?\n\nCheers.\n\n[1] https://www.reddit.com/r/kde/comments/7y6eds/kompare_is_a_great_difftool_why_doesnt_it_work_as/\n[2] https://github.com/whiteinge/diffconflicts/blob/master/_utils/README.md\n\n-- \nFelipe Contreras\n"},{"id":"412547","messageId":"xmqq3603v3a0.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"20201218054947.GA123376@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-18T10:04:23Z","receivedAt":"2020-12-18T10:05:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth House writes:\n\n> On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote:\n>> And no person is the sole arbiter of truth, in this list, or anywhere.\n>> People have managed to change Junio's mind.\n>\n> I'm not worried about Junio but I am wondering if anyone has managed to\n> change your mind. You and I have been going back and forth on this list\n> and on Reddit for two solid days and, to be frank, I'm running out of\n> steam.\n> ...\n> I, as a user of diffconflicts, may want to both disable this flag for\n> diffconflicts but enable this flag for VS Code and kdiff3. It is not\n> unusual for people to use more than one mergetool. Some of them are\n> better or worse at visualizing different kinds of conflicts. Sometimes\n> a conflict is small and straightforward; othertimes a conflict is\n> complicated and requires deep knowledge of the history of both branches.\n> If we force this to be a global flag only then users will not be able to\n> make different choices for different tools.\n>\n> Someone who does use multiple mergetools but only uses tools from group\n> one may appreciate a single global flag so s/he doesn't need to set it\n> for each tool.\n> ... there's every possibility that a user will prefer it a different\n> way or that a mergetool author will. And there's every possibility that\n> there will be differing opinions between users and authors like there is\n> between you and me. But that's ok! Because it's just a configuration\n> option.\n\nWell explained. I do not think I need to add much.\n\nIt makes sense to at least allow people to enable/disable the\nbehaviour independently for different tools. When unconfigured, I\nwould say we should enable the feature by default to give it wider\nexposure.\n\nBecause what I care is not about the set of tools we happen to have\nright now, but is about leaving users access to an escape hatch in\ncase things go wrong. If it turns out that all the tools we happen\nto have do not seem to break with this new option with just a few\ndays' survey, it does not mean we do not need a per-tool escape\nhatch they can use until the next release either fixes the feature\nor makes it disabled by default, when there is unexpected breakages\ndiscovered later. The time between a release and the next is a long\ntime that the users cannot keep the tool they have learned to rely\non broken. And that's a conservative maintainer's view.\n\nWhen a tool that never wants its input munged appears, we might\nfurther want to have the mechanism to give different default per\neach tool for users who have no configuration, so that such a tool\ncan be disabled while other tools are enabled by default while\nallowing users to choose. But such a code to set different\nenabled/disabled default per tool (the one I outlined in the\nfootnote of the other message) won't be exercised in practice with\nthe set of tools we have (hence a bug in such a code would go\nunnoticed for a long time), so I tend to think we might be better\noff to wait until the need arises before implementing per-tool\nfallback default for users who do not configure at all.\n\nAnother reason why allowing users to disable the feature per tool is\nimportant is because as far as I know we have kept the mergetool\nframework to allow adding a tool that can merge binary data, and\nleaving these three files pristine was one ingredient for that.\nWith only a single knob, we would be making a decision to declare\nthat such a tool is unwelcome, which is not quite acceptable. I\nexpect that users would want the new feature most of the time\nbecause they would be managing text files more of the time, and\nhaving only a single knob would force an unnecessary choice on those\nwho want to use such a binary-capable tool as well.\n"},{"id":"412552","messageId":"5fdc998216c89_104e15208da@natae.notmuch","threadId":"54839","inReplyTo":"xmqq3603v3a0.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-18T11:58:58Z","receivedAt":"2020-12-18T11:59:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Seth House writes:\n> \n> > On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote:\n> >> And no person is the sole arbiter of truth, in this list, or anywhere.\n> >> People have managed to change Junio's mind.\n> >\n> > I'm not worried about Junio but I am wondering if anyone has managed to\n> > change your mind. You and I have been going back and forth on this list\n> > and on Reddit for two solid days and, to be frank, I'm running out of\n> > steam.\n> > ...\n> > I, as a user of diffconflicts, may want to both disable this flag for\n> > diffconflicts but enable this flag for VS Code and kdiff3. It is not\n> > unusual for people to use more than one mergetool. Some of them are\n> > better or worse at visualizing different kinds of conflicts. Sometimes\n> > a conflict is small and straightforward; othertimes a conflict is\n> > complicated and requires deep knowledge of the history of both branches.\n> > If we force this to be a global flag only then users will not be able to\n> > make different choices for different tools.\n> >\n> > Someone who does use multiple mergetools but only uses tools from group\n> > one may appreciate a single global flag so s/he doesn't need to set it\n> > for each tool.\n> > ... there's every possibility that a user will prefer it a different\n> > way or that a mergetool author will. And there's every possibility that\n> > there will be differing opinions between users and authors like there is\n> > between you and me. But that's ok! Because it's just a configuration\n> > option.\n> \n> Well explained. I do not think I need to add much.\n> \n> It makes sense to at least allow people to enable/disable the\n> behaviour independently for different tools. When unconfigured, I\n> would say we should enable the feature by default to give it wider\n> exposure.\n> \n> Because what I care is not about the set of tools we happen to have\n> right now, but is about leaving users access to an escape hatch in\n> case things go wrong.\n\nThey do have an escape hatch.\n\n> If it turns out that all the tools we happen to have do not seem to\n> break with this new option with just a few days' survey,\n\nSeth's blog post was ten days ago, and I presume it took him more than\none day to write, so I'm not sure it's a \"few days' survey\".\n\n> it does not mean we do not need a per-tool escape\n> hatch they can use until the next release either fixes the feature\n> or makes it disabled by default, when there is unexpected breakages\n> discovered later.\n\nThey don't need to wait for the next release, they can just disable the\nflag.\n\nThese hypothetical users of multiple mergetools that are using a\nhypothetical mergetool that doesn't seem to exist yet can just disable\nthe flag globally.\n\nThese users have managed to survive many years without this feature\nenabled in all the usual mergetools, I think they would survive until\nthe next release.\n\n> The time between a release and the next is a long\n> time that the users cannot keep the tool they have learned to rely\n> on broken. And that's a conservative maintainer's view.\n\nThey don't have to; they can just disable the flag.\n\n> When a tool that never wants its input munged appears, we might\n> further want to have the mechanism to give different default per\n> each tool for users who have no configuration, so that such a tool\n> can be disabled while other tools are enabled by default while\n> allowing users to choose. But such a code to set different\n> enabled/disabled default per tool (the one I outlined in the\n> footnote of the other message) won't be exercised in practice with\n> the set of tools we have (hence a bug in such a code would go\n> unnoticed for a long time), so I tend to think we might be better\n> off to wait until the need arises before implementing per-tool\n> fallback default for users who do not configure at all.\n\nAgreed.\n\n> Another reason why allowing users to disable the feature per tool is\n> important is because as far as I know we have kept the mergetool\n> framework to allow adding a tool that can merge binary data, and\n> leaving these three files pristine was one ingredient for that.\n> With only a single knob, we would be making a decision to declare\n> that such a tool is unwelcome, which is not quite acceptable. I\n> expect that users would want the new feature most of the time\n> because they would be managing text files more of the time, and\n> having only a single knob would force an unnecessary choice on those\n> who want to use such a binary-capable tool as well.\n\nI can't imagine what that binary data could look like, and how any tool\ncould represent that to the user.\n\nBut either way \"git merge-file\" fails on those cases, so we can just\ncheck if the file is empty, and bail out.\n\nI've implemented that in the next version.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412609","messageId":"20201219001358.GA153461@ellen","threadId":"54839","inReplyTo":"5fdc7a7d3a933_f4673208d0@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-19T00:13:58Z","receivedAt":"2020-12-19T00:15:00Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Fri, Dec 18, 2020 at 03:46:37AM -0600, Felipe Contreras wrote:\n> Yes, with evidence and reasoning.\n\n[Citation needed]\n\n> Yes, but the author of diffconflicts is not infallible.\n> \n> Explain why the *users* of the diffconclits tool would be affected\n> negatively\n\nYou've got that right -- I'm definitely not infallible. My point isn't\nthat I'm right; my point is that is my *preference*. Other mergetool\nauthors may have different preferences.\n\nI think where we're not seeing eye-to-eye is that you're focusing on\npotential \"negative\" consequences whereas I'm talking about having more\ninformation about the merge rather than less.\n\nThere is very likely no negative consequences for most, if not all,\nmergetools. I wrote the initial version of diffconflicts ten years ago\nand I've been using it nearly every day since. I'm fairly confident in\nthe end result. What is a fact is there is undisputedly less information\nabout the merge if we overwrite LOCAL and REMOTE; as I've written,\nI think the tradeoff is worthwhile for most tools but a per-tool\nconfiguration will allow people that feel differently to choose\ndifferently.\n\nThis is where I will part this particular debate. If you are not arguing\nfor the sake of arguing and if you are genuinely willing to have your\nmind changed then I invite you to reread my blog post, rewatch my\nYouTube video, and reread parts this thread -- watch out for where\nI talk about why LOCAL and REMOTE (and BASE) are useful.\n\nCheers.\n\n"},{"id":"412610","messageId":"20201219001838.GB153461@ellen","threadId":"54839","inReplyTo":"xmqq3603v3a0.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-19T00:18:38Z","receivedAt":"2020-12-19T00:19:29Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Fri, Dec 18, 2020 at 02:04:23AM -0800, Junio C Hamano wrote:\n> When unconfigured, I\n> would say we should enable the feature by default to give it wider\n> exposure.\n\nI am unreasonably excited about that. :D\n\n> If it turns out that all the tools we happen\n> to have do not seem to break with this new option with just a few\n> days' survey, it does not mean we do not need a per-tool escape\n> hatch they can use until the next release either fixes the feature\n> or makes it disabled by default, when there is unexpected breakages\n> discovered later.\n\nWell said. I will try to complete that screenshot comparison part of the\nsurvey that I promised by tonight, or by this weekend at the latest.\n\n"},{"id":"412613","messageId":"5fdd4f22c473b_1d952220844@natae.notmuch","threadId":"54839","inReplyTo":"20201219001358.GA153461@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-19T00:53:54Z","receivedAt":"2020-12-19T00:54:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Fri, Dec 18, 2020 at 03:46:37AM -0600, Felipe Contreras wrote:\n> > Yes, but the author of diffconflicts is not infallible.\n> > \n> > Explain why the *users* of the diffconclits tool would be affected\n> > negatively\n> \n> You've got that right -- I'm definitely not infallible. My point isn't\n> that I'm right; my point is that is my *preference*. Other mergetool\n> authors may have different preferences.\n> \n> I think where we're not seeing eye-to-eye is that you're focusing on\n> potential \"negative\" consequences whereas I'm talking about having more\n> information about the merge rather than less.\n\nYes, but it's not due to some unreasonable hankering; it comes from a\ndeep philosophical reason, which is Karl Popper's falsifiability principle\n[1] that solves both the problems of induction and demarcation.\n\nTo put it plainly; if we want to know if all swans are white, where you claim\nthe negative, and I the positive; it's much easier for you to prove the\nnegative. All you need is *one* black swan.\n\nAnalogously in our case; all you need is *one* negative consequence to\nprove your point, while me providing one hundred success cases does not\nprove my point.\n\n> There is very likely no negative consequences for most, if not all,\n> mergetools.\n\nAgain: do you have *one* negative consequence that is present in tool a,\nbut not in tool b?\n\nYou say there is \"very likely no negative consequences\", but do you have\nevidence of *any* negative consequence?\n\n> I wrote the initial version of diffconflicts ten years ago and I've\n> been using it nearly every day since. I'm fairly confident in the end\n> result. What is a fact is there is undisputedly less information about\n> the merge if we overwrite LOCAL and REMOTE;\n\nBut it's objectively not useful information.\n\nEdit your make-conflicts.sh script, and remove the first paragraph from\npoem.txt.\n\nWhat happens when you run \"git merge\"?\n\nDoes it not complete the merge without *any* user interaction?\n\nDoesn't that mean that git considers the changes in the second paragraph\nto be non-conflicts?\n\n> This is where I will part this particular debate.\n\nAll right.\n\nI'm still waiting for anyone to provide *one* example of a negative\nconsequence.\n\nCheers.\n\n[1] https://en.wikipedia.org/wiki/Falsifiability\n\n-- \nFelipe Contreras\n"},{"id":"412626","messageId":"xmqq1rfmqc8g.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"20201219001358.GA153461@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-19T11:14:23Z","receivedAt":"2020-12-19T11:15:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth House writes:\n\n> I think where we're not seeing eye-to-eye is that you're focusing on\n> potential \"negative\" consequences whereas I'm talking about having more\n> information about the merge rather than less.\n>\n> There is very likely no negative consequences for most, if not all,\n> mergetools. I wrote the initial version of diffconflicts ten years ago\n> and I've been using it nearly every day since. I'm fairly confident in\n> the end result. What is a fact is there is undisputedly less information\n> about the merge if we overwrite LOCAL and REMOTE; as I've written,\n> I think the tradeoff is worthwhile for most tools but a per-tool\n> configuration will allow people that feel differently to choose\n> differently.\n\nThanks for stressing this point.\n\nWhen a user or developer asks for a reasonable feature (e.g.\nconfigurability to suit personal taste), especially when there is no\nobvious downside for adding it, the burden of proof is on the party\nwho refuses to add it---they are the ones who have to adequately\nexplain why adding it is actively harmful, not just the proposed\naddition is not necessary [*1*].\n\nThere is no need for any \"evidence\" of \"negative consequence\" at all\nto ask for a way to selectively enable or disable a new feature. A\nnew feature tends to trigger unexpected bugs in unseen corner cases\nmore than an older feature, even without any concrete numbers, and\nthat is good enough reason to insist an escape hatch that is easy to\naccess by users to exist.\n\nThis is especially true for a software with wide userbase, most of\nwhich do not run the bleeding edge version. That is how we get\nusers unstuck after releasing our software with a new feature with\nunforeseen consequences, before we can deliver fixed version in\ntheir hands.\n\n> This is where I will part this particular debate. If you are not arguing\n> for the sake of arguing and if you are genuinely willing to have your\n> mind changed then I invite you to reread my blog post, rewatch my\n> YouTube video, and reread parts this thread -- watch out for where\n> I talk about why LOCAL and REMOTE (and BASE) are useful.\n\nThanks for your contribution so far.\n\n\n[Footnote]\n\n*1* They are, however, not obligated to add the feature themselves.\nThey can just honestly say \"I did not understand the help offered to\nmake use of it\", or \"I am too busy, so I am not doing it\", or give\nany other reason or excuse for not doing so. And the rest of us can\ntake it from there by building on top.\n"},{"id":"412630","messageId":"5fdded2523e7e_1de0de208e1@natae.notmuch","threadId":"54839","inReplyTo":"xmqq1rfmqc8g.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-19T12:08:05Z","receivedAt":"2020-12-19T12:09:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Seth House writes:\n> \n> > I think where we're not seeing eye-to-eye is that you're focusing on\n> > potential \"negative\" consequences whereas I'm talking about having more\n> > information about the merge rather than less.\n> >\n> > There is very likely no negative consequences for most, if not all,\n> > mergetools. I wrote the initial version of diffconflicts ten years ago\n> > and I've been using it nearly every day since. I'm fairly confident in\n> > the end result. What is a fact is there is undisputedly less information\n> > about the merge if we overwrite LOCAL and REMOTE; as I've written,\n> > I think the tradeoff is worthwhile for most tools but a per-tool\n> > configuration will allow people that feel differently to choose\n> > differently.\n> \n> Thanks for stressing this point.\n> \n> When a user or developer asks for a reasonable feature (e.g.\n> configurability to suit personal taste), especially when there is no\n> obvious downside for adding it, the burden of proof is on the party\n> who refuses to add it\n\nSorry, but no.\n\nYou may be the final word in the git project, but the burden of proof is\nan essential part of logic, not project-dependent, and that's just not\nthe case.\n\n*Anyone* that makes any claim has the burden of proof.\n\nThat is enshrined in the latin maxim:\n\n Semper necessitas probandi incumbit ei qui agit.\n\n The necessity of proof always lies with the person who lays charges.\n\nThere is a reason why in the US justice system defendants are declared\n\"not guilty\", and not \"inocent\".\n\nI have written extensively about the subject, for example: First\nprinciples of logic [1].\n\nIf a woman is not wearing a wedding ring, the person that claims she is\nmarried has the burden of proof, but also the person that claims she is\nsingle. *Both* have the burden of proof. It's only the person that says\n\"we don't know\" that doesn't.\n\n\nIs the feature reasonable? If I claim that it's not reasonable, I have\nhe burden of proof, but if you claim that it is reasonable, so do you.\n\nThat's just a fact of logic.\n\n> ---they are the ones who have to adequately explain why adding it is\n> actively harmful, not just the proposed addition is not necessary\n> [*1*].\n\nNo. Both have the burden of proof.\n\nOnly the people in the default position (we don't know if the feature is\nreasonable or not) don't require burden of proof.\n\n> There is no need for any \"evidence\" of \"negative consequence\" at all\n> to ask for a way to selectively enable or disable a new feature.\n\nYes there is. Not to ask for a feature, but *demand* a feature.\n\nBut such burden has been met, which is why users can turn off\nmergetool.autoMerge, so they can already selectively disable the new\nfeature.\n\n> A new feature tends to trigger unexpected bugs in unseen corner cases\n> more than an older feature, even without any concrete numbers, and\n> that is good enough reason to insist an escape hatch that is easy to\n> access by users to exist.\n\nThat rationale is meeting its burden of proof.\n\nBut users do already have an escape hatch: \"mergetool.automerge=false\".\n\n\nOn the other hand the burden of proof for the claim that some tools\nmight want to disable this flag and not other tools has not been met.\n\n\nMoreover, ignoring arguments doesn't magically make the burden of proof\nfrom your side dissappear.\n\nIs there a conflict in this example?\n\n echo Hello > BASE\n echo Hello > LOCAL\n echo Hello. > REMOTE\n git merge-file -p LOCAL BASE REMOTE\n\nCheers.\n\n[1] https://felipec.substack.com/p/first-principles-of-logic\n\n-- \nFelipe Contreras\n"},{"id":"412661","messageId":"xmqqpn35odnm.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fdded2523e7e_1de0de208e1@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-19T18:26:37Z","receivedAt":"2020-12-19T18:27:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Seth House writes:\n>> \n>> > I think where we're not seeing eye-to-eye is that you're focusing on\n>> > potential \"negative\" consequences whereas I'm talking about having more\n>> > information about the merge rather than less.\n>> >\n>> > There is very likely no negative consequences for most, if not all,\n>> > mergetools. I wrote the initial version of diffconflicts ten years ago\n>> > and I've been using it nearly every day since. I'm fairly confident in\n>> > the end result. What is a fact is there is undisputedly less information\n>> > about the merge if we overwrite LOCAL and REMOTE; as I've written,\n>> > I think the tradeoff is worthwhile for most tools but a per-tool\n>> > configuration will allow people that feel differently to choose\n>> > differently.\n>> \n>> Thanks for stressing this point.\n>> \n>> When a user or developer asks for a reasonable feature (e.g.\n>> configurability to suit personal taste), especially when there is no\n>> obvious downside for adding it, the burden of proof is on the party\n>> who refuses to add it\n>\n> Sorry, but no.\n>\n> You may be the final word in the git project, but the burden of proof is\n> an essential part of logic, not project-dependent, and that's just not\n> the case.\n>\n> *Anyone* that makes any claim has the burden of proof.\n\nYes, and in this case, Seth already said he prefers to be able to\nsee the original, and not necessarily all the users of his mergetool\nbackend prefer the same thing. That is enough \"proof\" to me that\nthe need exists. It is your turn to prove your (implicit) claim\nthat it does more harm than it helps to allow such a preference\nexpressed by end users.\n\n> Is there a conflict in this example?\n>\n> echo Hello > BASE\n> echo Hello > LOCAL\n> echo Hello. > REMOTE\n> git merge-file -p LOCAL BASE REMOTE\n\nSorry, but I do not see why that example matters. Would such a case\neven come into the picture to be resolved by \"git mergetool\" in the\nfirst place?\n\n"},{"id":"412663","messageId":"xmqqlfdtoch2.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fdc998216c89_104e15208da@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-19T18:52:09Z","receivedAt":"2020-12-19T18:53:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> Another reason why allowing users to disable the feature per tool is\n>> important is because as far as I know we have kept the mergetool\n>> framework to allow adding a tool that can merge binary data, and\n>> leaving these three files pristine was one ingredient for that.\n>> With only a single knob, we would be making a decision to declare\n>> that such a tool is unwelcome, which is not quite acceptable. I\n>> expect that users would want the new feature most of the time\n>> because they would be managing text files more of the time, and\n>> having only a single knob would force an unnecessary choice on those\n>> who want to use such a binary-capable tool as well.\n>\n> I can't imagine what that binary data could look like, and how any tool\n> could represent that to the user.\n\nWhat I had in mind are use cases like merging \"comment\"-ish part of\nmedia files (e.g. exif in jpeg, id3 in mp3---things like that), as\nI've heard some people do use Git to manage their photo collection.\n\nOf course, I can imagine that a cartoonist first draws a background\npicture, cop es it twice, and then draws a dog on top of the\nbackground in one copy while drawing a cat in the other. You should\nbe able to merge the resulting two pictures cleanly by following the\nthree-way merge idea (take what got changed on only one side plus\nwhat did not change--anything else is a conflict) as long as these\nanimals do not overlap. You probably can even do an equivalent of\n-Xours (not --ours) to essentially say which object is closer to the\nviewer in a conflicting case.\n\n> But either way \"git merge-file\" fails on those cases, so we can just\n> check if the file is empty, and bail out.\n\nCatching failures from merge-file and reverting back to the original\nbehaviour would be an improvement, if the code in the earlier\niteration was not checking errors. But I would prefer not count on\nthe tool always to fail, as there are image file formats that appear\nto be text that are unreadable to humans (like pnm), and my primary\nreason for configurability is as an escape hatch to be used in cases\nwhere we do not anticipate here. Listing \"what about this case, it\ndoes not break\" million times would not help us here.\n\nWith per-tool enable/disable option, the users do not have to rely\non failure from merge-file anyway.\n\nThanks.\n"},{"id":"412666","messageId":"5fde601ee30f5_1e50c72081c@natae.notmuch","threadId":"54839","inReplyTo":"xmqqpn35odnm.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-19T20:18:38Z","receivedAt":"2020-12-19T20:19:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >> Seth House writes:\n> >> \n> >> > I think where we're not seeing eye-to-eye is that you're focusing on\n> >> > potential \"negative\" consequences whereas I'm talking about having more\n> >> > information about the merge rather than less.\n> >> >\n> >> > There is very likely no negative consequences for most, if not all,\n> >> > mergetools. I wrote the initial version of diffconflicts ten years ago\n> >> > and I've been using it nearly every day since. I'm fairly confident in\n> >> > the end result. What is a fact is there is undisputedly less information\n> >> > about the merge if we overwrite LOCAL and REMOTE; as I've written,\n> >> > I think the tradeoff is worthwhile for most tools but a per-tool\n> >> > configuration will allow people that feel differently to choose\n> >> > differently.\n> >> \n> >> Thanks for stressing this point.\n> >> \n> >> When a user or developer asks for a reasonable feature (e.g.\n> >> configurability to suit personal taste), especially when there is no\n> >> obvious downside for adding it, the burden of proof is on the party\n> >> who refuses to add it\n> >\n> > Sorry, but no.\n> >\n> > You may be the final word in the git project, but the burden of proof is\n> > an essential part of logic, not project-dependent, and that's just not\n> > the case.\n> >\n> > *Anyone* that makes any claim has the burden of proof.\n> \n> Yes, and in this case, Seth already said he prefers to be able to\n> see the original, and not necessarily all the users of his mergetool\n> backend prefer the same thing. That is enough \"proof\" to me that\n> the need exists.\n\nThat's not proof. That's one person stating his opinion.\n\nHe did not present evidence of *why* one of his users would prefer to\nturn this flag off in his tool, but not others.\n\nHere, allow me to show what diffconflicts does:\n\ndiff --git a/mergetools/vimdiff b/mergetools/vimdiff\nindex abc8ce4ec4..a8fd8e4a84 100644\n--- a/mergetools/vimdiff\n+++ b/mergetools/vimdiff\n@@ -29,6 +29,10 @@ merge_cmd () {\n \t\t\t\t\"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n \t\tfi\n \t\t;;\n+\t*vimdiff4)\n+\t\tcp \"$LOCAL\" \"$MERGED\"\n+\t\t\"$merge_tool_path\" -f -d \"$MERGED\" \"$REMOTE\"\n+\t\t;;\n \tesac\n }\n \n\n\"mergetool.automerge=true\" plus the code above replicates the main\nfunctionality of the diffconflicts plugin.\n\nWhy would anyone want to turn off automerge for vimdiff4, but not for\nvimdiff2?\n\nNobody has explained that.\n\n> It is your turn to prove your (implicit) claim that it does more harm\n> than it helps to allow such a preference expressed by end users.\n\nNo. The burden of proof is still on the side that claims such preference\nis desirable.\n\n\"I think X\" is not evidence of X.\n\n> > Is there a conflict in this example?\n> >\n> > echo Hello > BASE\n> > echo Hello > LOCAL\n> > echo Hello. > REMOTE\n> > git merge-file -p LOCAL BASE REMOTE\n> \n> Sorry, but I do not see why that example matters.\n\nBut I do. That's why I asked the question.\n\n> Would such a case even come into the picture to be resolved by \"git\n> mergetool\" in the first place?\n\nThat is precisely the point.\n\nIt is not a conflict because that line only has changes in REMOTE, but\nnot in LOCAL. Correct?\n\ngit doesn't bother the user because there's no merge conflict.\n\nBut if there is an *actual conflict* some lines below, why should git,\nor git-mergetool, or the mergetool now bother the user presenting it the\ndiff of the \"Hello.\" line?\n\nWhy does that line that according to you \"wouldn't not even come into\nthe picture\" becomes suddenly relevant when there's an actual conflict\nbelow?\n\nEither the \"Hello.\" change is relevant or it isn't.\n\nBut more importantly; its relevance doesn't depend on the mergetool.\n\nChoosing vimdiff4 doesn't magically make it a conflict.\n\nCheer.\n\n-- \nFelipe Contreras\n"},{"id":"412667","messageId":"5fde69944fe4d_1e50c7208f@natae.notmuch","threadId":"54839","inReplyTo":"xmqqlfdtoch2.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-19T20:59:00Z","receivedAt":"2020-12-19T21:00:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> Another reason why allowing users to disable the feature per tool is\n> >> important is because as far as I know we have kept the mergetool\n> >> framework to allow adding a tool that can merge binary data, and\n> >> leaving these three files pristine was one ingredient for that.\n> >> With only a single knob, we would be making a decision to declare\n> >> that such a tool is unwelcome, which is not quite acceptable. I\n> >> expect that users would want the new feature most of the time\n> >> because they would be managing text files more of the time, and\n> >> having only a single knob would force an unnecessary choice on those\n> >> who want to use such a binary-capable tool as well.\n> >\n> > I can't imagine what that binary data could look like, and how any tool\n> > could represent that to the user.\n> \n> What I had in mind are use cases like merging \"comment\"-ish part of\n> media files (e.g. exif in jpeg, id3 in mp3---things like that), as\n> I've heard some people do use Git to manage their photo collection.\n\nRight. They can do that with a text editor.\n\n> Of course, I can imagine that a cartoonist first draws a background\n> picture, cop es it twice, and then draws a dog on top of the\n> background in one copy while drawing a cat in the other. You should\n> be able to merge the resulting two pictures cleanly by following the\n> three-way merge idea (take what got changed on only one side plus\n> what did not change--anything else is a conflict) as long as these\n> animals do not overlap. You probably can even do an equivalent of\n> -Xours (not --ours) to essentially say which object is closer to the\n> viewer in a conflicting case.\n\nThe whole point of separating the background from the foreground is that\nthe foreground can be animated on top of the background, so they would\nalways be two different files.\n\nEven if we force the issue and make two graphic artists work on two\ndifferent branches, what they would inevitably end up doing is work on\ndifferent layers, which for all intents and purposes are like two files.\nNo mergetool is going to help them integrate their changes.\n\n> > But either way \"git merge-file\" fails on those cases, so we can just\n> > check if the file is empty, and bail out.\n> \n> Catching failures from merge-file and reverting back to the original\n> behaviour would be an improvement, if the code in the earlier\n> iteration was not checking errors. But I would prefer not count on\n> the tool always to fail, as there are image file formats that appear\n> to be text that are unreadable to humans (like pnm),\n\ngit would not add conflict markers on the part of a pnm file that did\nnot change, so in fact, a person merging pnm files might in fact desire\nautomerge.\n\n> and my primary reason for configurability is as an escape hatch to be\n> used in cases where we do not anticipate here.\n\nOnce again: \"mergetool.automerge=false\" is a thing.\n\n> Listing \"what about this case, it does not break\" million times would\n> not help us here.\n\nThis is the philosophical problem of induction: a million white swans\ndoesn't prove all swans are white.\n\nThe only thing we know for certain is that there is no known problem.\nAnd that if and when such a problem occurs, we would need to think about\nthe proper solution.\n\n> With per-tool enable/disable option, the users do not have to rely\n> on failure from merge-file anyway.\n\nThey don't have to rely on that failure, they can just turn off\nmergetool.automerge.\n\n\nBut fine. Let's the perfect be the enemy of the good. That seems wise.\n\n-- \nFelipe Contreras\n"},{"id":"412676","messageId":"CAJDDKr6RP+TPFF2mHph7sqa-eG9uoRtqS4d4vUU84V3HJ_CMBA@mail.gmail.com","threadId":"54839","inReplyTo":"5fde69944fe4d_1e50c7208f@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2020-12-20T06:44:54Z","receivedAt":"2020-12-20T06:46:28Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras\n wrote:\n>\n> Junio C Hamano wrote:\n> > Felipe Contreras writes:\n> >\n> > >> Another reason why allowing users to disable the feature per tool is\n> > >> important is because as far as I know we have kept the mergetool\n> > >> framework to allow adding a tool that can merge binary data, and\n> > >> leaving these three files pristine was one ingredient for that.\n> > >> With only a single knob, we would be making a decision to declare\n> > >> that such a tool is unwelcome, which is not quite acceptable. I\n> > >> expect that users would want the new feature most of the time\n> > >> because they would be managing text files more of the time, and\n> > >> having only a single knob would force an unnecessary choice on those\n> > >> who want to use such a binary-capable tool as well.\n> > >\n> > > I can't imagine what that binary data could look like, and how any tool\n> > > could represent that to the user.\n> >\n> > What I had in mind are use cases like merging \"comment\"-ish part of\n> > media files (e.g. exif in jpeg, id3 in mp3---things like that), as\n> > I've heard some people do use Git to manage their photo collection.\n>\n> Right. They can do that with a text editor.\n>\n> > Of course, I can imagine that a cartoonist first draws a background\n> > picture, cop es it twice, and then draws a dog on top of the\n> > background in one copy while drawing a cat in the other. You should\n> > be able to merge the resulting two pictures cleanly by following the\n> > three-way merge idea (take what got changed on only one side plus\n> > what did not change--anything else is a conflict) as long as these\n> > animals do not overlap. You probably can even do an equivalent of\n> > -Xours (not --ours) to essentially say which object is closer to the\n> > viewer in a conflicting case.\n>\n> The whole point of separating the background from the foreground is that\n> the foreground can be animated on top of the background, so they would\n> always be two different files.\n>\n> Even if we force the issue and make two graphic artists work on two\n> different branches, what they would inevitably end up doing is work on\n> different layers, which for all intents and purposes are like two files.\n> No mergetool is going to help them integrate their changes.\n>\n> > > But either way \"git merge-file\" fails on those cases, so we can just\n> > > check if the file is empty, and bail out.\n> >\n> > Catching failures from merge-file and reverting back to the original\n> > behaviour would be an improvement, if the code in the earlier\n> > iteration was not checking errors. But I would prefer not count on\n> > the tool always to fail, as there are image file formats that appear\n> > to be text that are unreadable to humans (like pnm),\n>\n> git would not add conflict markers on the part of a pnm file that did\n> not change, so in fact, a person merging pnm files might in fact desire\n> automerge.\n>\n> > and my primary reason for configurability is as an escape hatch to be\n> > used in cases where we do not anticipate here.\n>\n> Once again: \"mergetool.automerge=false\" is a thing.\n>\n> > Listing \"what about this case, it does not break\" million times would\n> > not help us here.\n>\n> This is the philosophical problem of induction: a million white swans\n> doesn't prove all swans are white.\n>\n> The only thing we know for certain is that there is no known problem.\n> And that if and when such a problem occurs, we would need to think about\n> the proper solution.\n>\n> > With per-tool enable/disable option, the users do not have to rely\n> > on failure from merge-file anyway.\n>\n> They don't have to rely on that failure, they can just turn off\n> mergetool.automerge.\n>\n>\n> But fine. Let's the perfect be the enemy of the good. That seems wise.\n\n\nFWIW I'm in favor of having per-tool configuration precisely for\ncustom mergetools that do things with custom file formats and benefit\nfrom having all of LOCAL REMOTE and BASE.\n\nI don't have to imagine these use cases, they are very real. No survey\ncan be exhaustive so being flexible and allowing for a mixed tool\necosystem is the right choice.\n\nThis design choice is also in alignment with the general\nmergetool/difftool per-tool configuration paradigm. If we didn't\nsupport per-tool, then it would be inconsistent.\n-- \nDavid\n\n(sorry, posting from gmail's web interface so this probably won't hit\nthe public lists, but I probably won't reply beyond this email stating\nmy preference)\n"},{"id":"412678","messageId":"5fdf030d2bde5_32bc20825@natae.notmuch","threadId":"54839","inReplyTo":"CAJDDKr6RP+TPFF2mHph7sqa-eG9uoRtqS4d4vUU84V3HJ_CMBA@mail.gmail.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-20T07:53:49Z","receivedAt":"2020-12-20T07:54:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Aguilar wrote:\n> On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras\n> wrote:\n> > They don't have to rely on that failure, they can just turn off\n> > mergetool.automerge.\n> >\n> >\n> > But fine. Let's the perfect be the enemy of the good. That seems wise.\n> \n> FWIW I'm in favor of having per-tool configuration precisely for\n> custom mergetools that do things with custom file formats and benefit\n> from having all of LOCAL REMOTE and BASE.\n\nThat's a preference, not an argument.\n\n> I don't have to imagine these use cases, they are very real.\n\nShow one.\n\n> This design choice is also in alignment with the general\n> mergetool/difftool per-tool configuration paradigm. If we didn't\n> support per-tool, then it would be inconsistent.\n\nCan you do\n\n 1. mergetool.vimdiff3.keepBackup\n 2. mergetool.vimdiff3.keepTemporaries\n 3. mergetool.vimdiff3.writeToTemp\n 4. mergetool.vimdiff3.prompt\n\n?\n\nIn fact the opposite is the case; not a *single* `mergetool.foo`\nconfiguration can be done with `mergetool..foo`.\n\n-- \nFelipe Contreras\n"},{"id":"412684","messageId":"20201221042501.GA146725@ellen","threadId":"54839","inReplyTo":"xmqq1rfmqc8g.fsf@gitster.c.googlers.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-21T04:25:01Z","receivedAt":"2020-12-21T04:26:06Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Sat, Dec 19, 2020 at 03:14:23AM -0800, Junio C Hamano wrote:\n> Seth House writes:\n> > This is where I will part this particular debate.\n> \n> Thanks for your contribution so far.\n\nRe-reading my message now, I sounded overly final. I appreciated your\ninitial warm welcome and I'm still very much present on this list and\nstill very much invested in seeing this patch through to consensus and\ncompletion -- and that includes writing code if needed.\n\nTo rephrase: I don't wish to spend any more of my time debating\n`mergetool.autoMerge`\nvs.\n`mergetool.autoMerge || mergetool.$tool.autoMerge`\nand I appreciate that others on this list have joined that debate.\nI think all the angles and opinions have been covered at this point so\nperhaps the time has come for a vote or for an executive decision.\n\n---\n\nThe task of re-reviewing all the mergetools surveyed in the original\nblog post is now complete. I took the opportunity to update most of the\noriginal post to reflect the discussion and audience here.\n\nhttps://www.eseth.org/2020/mergetools.html\n\nThe \"Mergetools Comparison\" section is long and is not very easy to read\nwith the current layout. Sorry. I wanted to get this published quickly\nand I'll try to clean it up and add a proper TOC. For now, watch out for\nthe \"Summary\" under each tool.\n\ntl;dr: I didn't see any noteworthy problems with any tool. Mostly\npositive results and some no-impact results. The two minor impacts were\nfrom the two tools that make use of LOCAL and REMOTE as historical\nreferences; I think those are safe to ignore because one is mine and the\nother builds on mine. All the other surveyed tools that reference older\nversions of the conflicted file appear to actively query the Git\nrepository to obtain that info.\n\nI'd still like to add more tools and do deeper dives with some of the\ntools already surveyed so suggestions, feedback, and criticisms are very\nwelcome. That said, I am now feeling comfortable about adding this to\nGit and defaulting it to enabled. :D\n\n"},{"id":"412685","messageId":"5fdffe7f7fbd_89f120860@natae.notmuch","threadId":"54839","inReplyTo":"CAJDDKr5EiH3R284XNToTkVQ1a12Mqp7oCA30xpt_cMjatfHQjg@mail.gmail.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-21T01:46:39Z","receivedAt":"2020-12-21T04:31:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Aguilar wrote:\n> On Sat, Dec 19, 2020 at 11:53 PM Felipe Contreras\n> wrote:\n> >\n> > David Aguilar wrote:\n> > > On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras\n> > > wrote:\n> > > > They don't have to rely on that failure, they can just turn off\n> > > > mergetool.automerge.\n> > > >\n> > > >\n> > > > But fine. Let's the perfect be the enemy of the good. That seems wise.\n> > >\n> > > FWIW I'm in favor of having per-tool configuration precisely for\n> > > custom mergetools that do things with custom file formats and benefit\n> > > from having all of LOCAL REMOTE and BASE.\n> >\n> > That's a preference, not an argument.\n> \n> Lol, that's why I said \"in favor\". But, since you asked, it turns out\n> that my preferences have a stronger weight than yours.\n> \n> \"git shortlog -n git-difftool* git-mergetool*\" shows that my\n> preferences and opinions are 44 times more important than yours in\n> this area, whether you like it or not. ;-p\n\nThat doesn't mean you are right.\n\nThis is an appeal to authority fallacy.\n\n> Poking fun is my answer to such misguided seriousness.\n\nI did not poke fun. I was just pointing out the fact that it wasn't an\nargument.\n\n> > > I don't have to imagine these use cases, they are very real.\n> >\n> > Show one.\n> \n> Heh, I don't have to show you anything.\n\nNo you don't, but in a discussion with other people if you don't\nsubstantiate your claims, then others have no rational reason to\nconsider them.\n\n> Barring that, please use your imagination. Imagine a custom file\n> format for a graph-like data structure (both binary and text-like)\n> that is able to use the full set of information for the purposes of\n> resolving conflicts. Private tools exist. It's impossible to prove\n> that they don't so I won't ask you or anyone else to do so.\n\nSo it's not a real use-case, it's an imaginary one.\n\nEven if we do consider this imaginary use-case, you just swept the\nproblem under the carpet by saying \"is able to use the full set of\ninformation\".\n\nHow?\n\nExplain how this tool would use this information.\n\n> > > This design choice is also in alignment with the general\n> > > mergetool/difftool per-tool configuration paradigm. If we didn't\n> > > support per-tool, then it would be inconsistent.\n> >\n> > Can you do\n> >\n> > 1. mergetool.vimdiff3.keepBackup\n> > 2. mergetool.vimdiff3.keepTemporaries\n> > 3. mergetool.vimdiff3.writeToTemp\n> > 4. mergetool.vimdiff3.prompt\n> \n> can_merge()\n> diff_cmd()\n> merge_cmd()\n> translate_merge_tool_path()\n> list_tool_variants()\n> exit_code_trustable()\n> \n> mergetool..cmd\n> mergetool..path\n> mergetool..trustExitCode\n\nNone of those are user preferences.\n\n> We even have mergetool.meld.hasOutput which is completely tool-specific.\n\nWe don't have a user preference `mergetool.hasOutput`, or\n`mergetool.vimdiff3.hasOutput` for that matter.\n \n> I'm not asking, I'm telling you: the tool was designed around per-tool\n> hooks. This is per-tool behavior. End of story.\n\nAnd yet a tool cannot override `mergetool.keepBackup`.\n\nCorrect?\n\n> > ?\n> >\n> > In fact the opposite is the case; not a *single* `mergetool.foo`\n> > configuration can be done with `mergetool..foo`.\n> \n> That's not the right question. This a behavior that can differ\n> per-tool and thus this feature must reflect that.\n\nCan it?\n\nI am waiting for somebody to show *how*.\n\n> There is a difference between top-level and per-tool behavior.\n\n> This is a per-tool feature\n\nNo, that's your opinion. You haven't explained why.\n\n> The way to think about it is that it's a per-tool feature\n\nDitto.\n\n> We are not designing just for today; we must keep our eye on\n> longer-term goals where the community tools can be improved.\n\nYes, but an actual future that might actually happen.\n\n> Here is the \"right\" question to ask: Why shouldn't we have this\n> flexibility?\n\nWhy shouldn't we have `mergetool.vimdiff3.keepBackup`?\n\n> The heavy hammer of completely disabling the feature means that they\n> will have crippled all of the other mergetools just because one of\n> them couldn't cope,\n\nPrecisely *how* a tool couldn't cope?\n\n> Are you willing to compromise on the small concession that we should\n> allow per-tool overrides so that we can move forward and get this\n> integrated?\n\nWe can move forward right now.\n\nBut no, I am 99.99% certain *nobody* will ever implement\nshould_automerge (), so I won't waste my time with it.\n\nIf you think otherwise, you spend your time implementing this on top of\nmy patch. That way it's clear who made the mistake.\n\n> To be extremely clear -- is this discussion arguing between the\n> following two strategies?\n> \n> # Per-tool override + Global default\n> \n> should_automerge () {\n> git config mergetool.$tool.automerge || git config\n> mergetool.automerge || echo true\n> }\n> \n> # vs. Global default only\n> \n> should_automerge () {\n> git config mergetool.automerge || echo true\n> }\n> \n> , or are we discussing a different aspect? When spelled out in code,\n> we're discussing whether or not we should have\n> \"mergetool.$tool.automerge ||\" in there, and the argument for why not\n> is pretty thin considering that use cases that would be harmed by not\n> doing so exist.\n\nI don't think mergetool.autoMerge should be any different from\nmergetool.keepBackup; a single global user configuration suffices.\n\nYou say the argument against such per-tool configuration is thin, I say\nthe argument in favor is non-existent.\n\n> Such a trivial difference is not a hill worth dying on so please route\n> this energy into a patch so that we can get this integrated.\n\nNobody can tell me how I chose to spend my free time that I'm choosing to\ncontribute to this project altruistically.\n\n> I suggest this compromise -- if adding \"mergetool.$tool.automerge ||\"\n> to the logic is something you don't want to do then submit the patch\n> without it and I'll submit a follow-up patch that adds the per-tool\n> override.\n\nThat's not a compromise. That's a difference of opinion stated in the\ncode.\n\nI don't have to convince you. And you don't have to convince me.\n\n> I'd personally prefer to just have the patch include this from the\n> get-go, though, so if we've managed to convince you then please take\n> the shorter path to success.\n\nAnd I would prefer that we don't waste time with hypothetical use-cases\nthat will never materialize.\n\nWe can add such configuration when the need actually arises.\n\nBut we can't always have what we prefer.\n\nCheers.\n\n[1] https://en.wikipedia.org/wiki/Argument_from_authority\n\n-- \nFelipe Contreras\n"},{"id":"412694","messageId":"5fdfecd47e17f_89f120852@natae.notmuch","threadId":"54839","inReplyTo":"CANiSa6jMXTyfo43bUdC8601BvYKiF67HXo+QaiTh_-8KWyBsLg@mail.gmail.com","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-21T00:31:16Z","receivedAt":"2020-12-21T05:08:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Martin von Zweigbergk wrote:\n> On Thu, Dec 17, 2020, 16:52 Felipe Contreras \n> wrote:\n> \n> > Junio C Hamano wrote:\n> > > Many people may stick to just a single tool and may find a single\n> > > mergetool.autoMerge knob convenient (and it is OK for them if the\n> > > new behaviour broke a tool they do not use), but for those who use\n> > > more than one, being able to configure them differently would be\n> > > valuable.\n> >\n> > On what tool would you turn this on, and what tool would you turn this\n> > off?\n> \n> Maybe turn it off for a mergetool smart enough to understand the semantics\n> of the change?\n> \n> Let's say BASE contains a function foo(). LOCAL renames foo() to bar() and\n> OTHER adds a call to foo(). The tool would need to know that the call to\n> foo() was added in order to know that it should be renamed in the output.\n\nThat's true, but that's something we would want in git itself, not the\nmergetool.\n\nIf there are no conflicts, \"git merge\" would simply do the automatic\nmerge, and this magical semantic mergetool would never have an\nopportunity to run.\n\n> I've only skimmed this thread, so I apologize if I've misunderstood the\n> quotation or if my point has already been brought up.\n\nNobody has made this point. And it's the kind of rationale I was looking\nfor.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412698","messageId":"5fe033e0ec278_96932089d@natae.notmuch","threadId":"54839","inReplyTo":"20201221042501.GA146725@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-21T05:34:24Z","receivedAt":"2020-12-21T05:35:28Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> To rephrase: I don't wish to spend any more of my time debating\n> `mergetool.autoMerge`\n> vs.\n> `mergetool.autoMerge || mergetool.$tool.autoMerge`\n> and I appreciate that others on this list have joined that debate.\n\n> I think all the angles and opinions have been covered at this point so\n> perhaps the time has come for a vote or for an executive decision.\n\nI disagree. It's fine if you don't want to participate, but the fact\nremains that the position that some tools would want to turn this off\nhasn't been properly defended.\n\n> The task of re-reviewing all the mergetools surveyed in the original\n> blog post is now complete. I took the opportunity to update most of the\n> original post to reflect the discussion and audience here.\n> \n> https://www.eseth.org/2020/mergetools.html\n\nThanks for doing this, but unfortunately one of the most popular isn't\nlisted there: vimdiff2.\n\n> The \"Mergetools Comparison\" section is long and is not very easy to read\n> with the current layout. Sorry. I wanted to get this published quickly\n> and I'll try to clean it up and add a proper TOC. For now, watch out for\n> the \"Summary\" under each tool.\n> \n> tl;dr: I didn't see any noteworthy problems with any tool. Mostly\n> positive results and some no-impact results.\n\nThat's what I expected.\n\n> The two minor impacts were from the two tools that make use of LOCAL\n> and REMOTE as historical references; I think those are safe to ignore\n> because one is mine and the other builds on mine. All the other\n> surveyed tools that reference older versions of the conflicted file\n> appear to actively query the Git repository to obtain that info.\n\nIn both you say \"identical output\". The only \"adverse effects\" are in\nthe secondary view, which you didn't present.\n\nCan you show these \"adverse effects\"?\n\n> I'd still like to add more tools and do deeper dives with some of the\n> tools already surveyed so suggestions, feedback, and criticisms are very\n> welcome. That said, I am now feeling comfortable about adding this to\n> Git and defaulting it to enabled. :D\n\nCool.\n\nFortunately in the unlikely situation that somebody manages to find a\ntool with adverse effects they can just disable the flag.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412701","messageId":"CAJDDKr5EiH3R284XNToTkVQ1a12Mqp7oCA30xpt_cMjatfHQjg@mail.gmail.com","threadId":"54839","inReplyTo":"5fdf030d2bde5_32bc20825@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2020-12-20T22:22:25Z","receivedAt":"2020-12-21T05:49:39Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sat, Dec 19, 2020 at 11:53 PM Felipe Contreras\n wrote:\n>\n> David Aguilar wrote:\n> > On Sat, Dec 19, 2020 at 12:59 PM Felipe Contreras\n> > wrote:\n> > > They don't have to rely on that failure, they can just turn off\n> > > mergetool.automerge.\n> > >\n> > >\n> > > But fine. Let's the perfect be the enemy of the good. That seems wise.\n> >\n> > FWIW I'm in favor of having per-tool configuration precisely for\n> > custom mergetools that do things with custom file formats and benefit\n> > from having all of LOCAL REMOTE and BASE.\n>\n> That's a preference, not an argument.\n\nLol, that's why I said \"in favor\". But, since you asked, it turns out\nthat my preferences have a stronger weight than yours.\n\n\"git shortlog -n git-difftool* git-mergetool*\" shows that my\npreferences and opinions are 44 times more important than yours in\nthis area, whether you like it or not. ;-p\n\nPoking fun is my answer to such misguided seriousness.\n\n\n> > I don't have to imagine these use cases, they are very real.\n>\n> Show one.\n\nHeh, I don't have to show you anything. If you *really* want to see\none then I would be super happy to get your resume, but I doubt I can\nconvince you to go that far!\n\nBarring that, please use your imagination. Imagine a custom file\nformat for a graph-like data structure (both binary and text-like)\nthat is able to use the full set of information for the purposes of\nresolving conflicts. Private tools exist. It's impossible to prove\nthat they don't so I won't ask you or anyone else to do so.\n\n\n> > This design choice is also in alignment with the general\n> > mergetool/difftool per-tool configuration paradigm. If we didn't\n> > support per-tool, then it would be inconsistent.\n>\n> Can you do\n>\n> 1. mergetool.vimdiff3.keepBackup\n> 2. mergetool.vimdiff3.keepTemporaries\n> 3. mergetool.vimdiff3.writeToTemp\n> 4. mergetool.vimdiff3.prompt\n\ncan_merge()\ndiff_cmd()\nmerge_cmd()\ntranslate_merge_tool_path()\nlist_tool_variants()\nexit_code_trustable()\n\nmergetool..cmd\nmergetool..path\nmergetool..trustExitCode\n\nWe even have mergetool.meld.hasOutput which is completely tool-specific.\n\nI'm not asking, I'm telling you: the tool was designed around per-tool\nhooks. This is per-tool behavior. End of story.\n\n\n> ?\n>\n> In fact the opposite is the case; not a *single* `mergetool.foo`\n> configuration can be done with `mergetool..foo`.\n\nThat's not the right question. This a behavior that can differ\nper-tool and thus this feature must reflect that.\n\nThere is a difference between top-level and per-tool behavior. This\nis a per-tool feature and we want a way for users to be able to\nenable/disable it globally while still enabling/disabling for an\nindividual tool. We must allow individual tools to expose their\nenhanced capabilities, otherwise the community tools have no reason to\nimprove, and private tools would be harmed.\n\nThe way to think about it is that it's a per-tool feature with a\ntop-level default. The important implementation detail is that tools\nhave plenty of hooks for per-tool flexibility; the configuration is\njust one way that we allow for it. The scriplet for something like\n\"diffconflicts\" could even override should_automerge() to return false\nsince it might want to handle it itself, for example.\n\nWe are not designing just for today; we must keep our eye on\nlonger-term goals where the community tools can be improved.\n\nI'm in favor of the auto-merge feature in general, and think it should\nbe made the default behavior (in a future version?). That said, it\nentails a change in behavior and having a granular mechanism to both\nallow enhanced tools to do their own thing, and to allow the original\nbehavior to be retained, is the most sensible approach.\n\nHere is the \"right\" question to ask: Why shouldn't we have this\nflexibility? The implementation is pretty darn simple considering\nthat the toolset is already designed with per-tool affordances in\nmind, so why not?\n\nWhat I am 100% certain about is that someone is going to notice the\nchange in behavior, and whether or not it's \"better\" is completely\nirrelevant. The heavy hammer of completely disabling the feature\nmeans that they will have crippled all of the other mergetools just\nbecause one of them couldn't cope, or because for whatever reason they\nwant the old behavior, so we should turn that heavy hammer into a\nfine-grained chisel.\n\nAre you willing to compromise on the small concession that we should\nallow per-tool overrides so that we can move forward and get this\nintegrated?\n\n\nTo be extremely clear -- is this discussion arguing between the\nfollowing two strategies?\n\n# Per-tool override + Global default\n\nshould_automerge () {\n git config mergetool.$tool.automerge || git config\nmergetool.automerge || echo true\n}\n\n# vs. Global default only\n\nshould_automerge () {\n git config mergetool.automerge || echo true\n}\n\n, or are we discussing a different aspect? When spelled out in code,\nwe're discussing whether or not we should have\n\"mergetool.$tool.automerge ||\" in there, and the argument for why not\nis pretty thin considering that use cases that would be harmed by not\ndoing so exist.\n\nSuch a trivial difference is not a hill worth dying on so please route\nthis energy into a patch so that we can get this integrated.\n\nI suggest this compromise -- if adding \"mergetool.$tool.automerge ||\"\nto the logic is something you don't want to do then submit the patch\nwithout it and I'll submit a follow-up patch that adds the per-tool\noverride.\n\nI'd personally prefer to just have the patch include this from the\nget-go, though, so if we've managed to convince you then please take\nthe shorter path to success.\n-- \nDavid\n"},{"id":"412706","messageId":"20201221073633.GA157132@ellen","threadId":"54839","inReplyTo":"5fe033e0ec278_96932089d@natae.notmuch","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Seth House","fromEmail":"seth@eseth.com","sentAt":"2020-12-21T07:36:33Z","receivedAt":"2020-12-21T07:37:20Z","isPatch":true,"sender":{"key":"seth@eseth.com","avatar":"https://avatars.githubusercontent.com/u/91293?v=4"},"body":"On Sun, Dec 20, 2020 at 11:34:24PM -0600, Felipe Contreras wrote:\n> I disagree. It's fine if you don't want to participate, but the fact\n> remains that the position that some tools would want to turn this off\n> hasn't been properly defended.\n\nIf you are _genuinely_ interested in the answer to this question, please\nread the section in my post titled \"Conflict Resolution\" followed by the\nsub-section \"Custom Merge Algorithm\", and finally \"Merge algorithms\" [1]\non Wikipedia. Then pretend you want to write your own conflict\nresolution algorithm for a new mergetool you've been dreaming up and ask\nyourself what versions of the conflicted file your tool will need.\n\n[1] https://en.wikipedia.org/wiki/Merge_(version_control)#Merge_algorithms\n\nRight now the algorithm Git uses is pretty best-in-class so it might\nseem unlikely that someone would want to write one of those. However\na whopping *seven* of the tools surveyed do just that. Some of them even\ndo a pretty good job (I've tried to point those out in the reviews).\nYou're preoccupied with identifying a specific \"adverse effect\" but this\ndebate isn't about that -- it's about giving individual tools the option\nto choose how they are used. If people out there want to try and write\na better algorithm than Git, I want to see them try.\n\nThat's the point I've been trying to drive home and that's the point\nthat David also made in his last reply to you.\n\nOn that note: you replied to David and said:\n\n> [Y]ou spend your time implementing this on top of my patch. That way\n> it's clear who made the mistake.\n\nI plan to start work on exactly that tomorrow. You made the initial\npatch so if you'd prefer to take it over the finish line yourself I'll\ndefer. But if you're not interested then I would be happy to credit you\nand finish it.\n\n> Thanks for doing this, but unfortunately one of the most popular isn't\n> listed there: vimdiff2.\n\nIt's under the Vim section. Use the page search in your browser for\n\"vimdiff2\".\n\n> That's what I expected.\n\nThat's what we all expected. The purpose of this follow-up survey was to\nvalidate that expectation.\n\n"},{"id":"412712","messageId":"5fe08449f3bd1_9b3120865@natae.notmuch","threadId":"54839","inReplyTo":"20201221073633.GA157132@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-21T11:17:30Z","receivedAt":"2020-12-21T11:18:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Seth House wrote:\n> On Sun, Dec 20, 2020 at 11:34:24PM -0600, Felipe Contreras wrote:\n> > I disagree. It's fine if you don't want to participate, but the fact\n> > remains that the position that some tools would want to turn this off\n> > hasn't been properly defended.\n> \n> If you are _genuinely_ interested in the answer to this question,\n\nIt's not about an answer to any specific question, defending a position\nrequires for you to answer any subsequent questions, like the one I made\nhere [1], which you never answered.\n\n> please read the section in my post titled \"Conflict Resolution\"\n> followed by the sub-section \"Custom Merge Algorithm\", and finally\n> \"Merge algorithms\" [1] on Wikipedia.\n> [1] https://en.wikipedia.org/wiki/Merge_(version_control)#Merge_algorithms\n\nI had already read your blog post, and OK; I read that section in\nWikipedia.\n\n> Then pretend you want to write your own conflict resolution algorithm\n> for a new mergetool you've been dreaming up and ask yourself what\n> versions of the conflicted file your tool will need.\n\nI don't dream of writing my own conflict resolution algorithm, but if I\ndid it, would be to be used *before* the mergetool, before git makes the\ndecision to bother the user to resolve the conflicts manually, before it\ndecides there are actual conflicts, and before it writes the conflict\nmarkers in the file.\n\nIn fact, it would work without any mergetool, that way the people that\nlike to edit the file directly (which you mentioned in your blog post\nare actually the majority of your coworkers) can benefit from such\nan algorithm.\n\n\nI answered yours, now you answer mine [1]. What happens if you remove\nthe first paragraph of your make-conflicts.sh script?\n\nWould a user have the chance to run \"git mergetool\" in those situations?\n\n echo \"The frumious bandersnatch!\" > BASE\n echo \"The frumious bandersnatch!\" > LOCAL\n echo \"The frumious Bandersnatch!\" > REMOTE\n git merge-file -p LOCAL BASE REMOTE\n\n> Right now the algorithm Git uses is pretty best-in-class so it might\n> seem unlikely that someone would want to write one of those.\n\nAnd yet that's what Elijah Newren is doing with his merge-ort proposal\nwhich is flying right now.\n\nYou want these algorithms to run in \"git merge\", not \"git mergetool\".\n\n> However a whopping *seven* of the tools surveyed do just that.\n\nBecause they are used in other situations, like working with subversion,\nnot just in git merge conflicts.\n\n> Some of them even do a pretty good job (I've tried to point those out\n> in the reviews).\n\nBetter than git?\n\n> You're preoccupied with identifying a specific \"adverse effect\" but this\n> debate isn't about that -- it's about giving individual tools the option\n> to choose how they are used.\n\nYes, individual *real* tools that either exist, or could actually exist.\n\n> If people out there want to try and write a better algorithm than Git,\n> I want to see them try.\n\nYes, and we want that algorithm to be used *before* the mergetool.\n\nMoreover, if any merge algorithm hopes to do better than git, it would\nrequire more than just 3 versions of the file; it would require to look\nat the commit graph.\n\nIf you somehow managed to create such an algorithm that is better than\ngit, you certainly wouldn't give it out for free, and it wouldn't be on\na puny mergetool to be used only when git thinks there are conflicts; it\nwould be a solution to be used *at every merge*.\n\nAnd that's what a *real* tool, Plastic SCM [2], does; it's a complete\nsolution that claims to have a better merge algorithm than Git.\n\n> That's the point I've been trying to drive home and that's the point\n> that David also made in his last reply to you.\n> \n> On that note: you replied to David and said:\n> \n> > [Y]ou spend your time implementing this on top of my patch. That way\n> > it's clear who made the mistake.\n> \n> I plan to start work on exactly that tomorrow. You made the initial\n> patch so if you'd prefer to take it over the finish line yourself I'll\n> defer. But if you're not interested then I would be happy to credit you\n> and finish it.\n\nIt is already at the finish line (I just need to update the commit\nmessage).\n\nIf you take my patch and add a bunch of unnecessary code, then remove my\n'Signed-off-by' line, because I don't approve of those changes.\n\nBetter yet; add *your* changes on a separate commit on top of my patch.\nThat way it's clear who did the meat of the changes, and who did the\nunnecessary ones.\n\n> > Thanks for doing this, but unfortunately one of the most popular isn't\n> > listed there: vimdiff2.\n> \n> It's under the Vim section. Use the page search in your browser for\n> \"vimdiff2\".\n\nIt says \"The vimdiff, vimdiff3, and vimdiff2 mergetools are not\nindividually detailed because they're all variations on the same theme\".\nSo yeah; no screenshots.\n\nAnd I disagree; vimdiff2 looks completely different from vimdiff. If you\nhave to choose one, you should choose vimdiff2, which is what everyone\nin the reddit thread you posted on r/git told you they use, not vimdiff.\n\nYou shouldn't deliberately chose the worst option that nobody uses.\n\nMoreover, the main view of your mergetool can be considered a variation\nalso, I can replicate the behavior with the following vimdiff4:\n\n \"$merge_tool_path\" -f -d -c 'wincmd l | %d | read #1 | 1d | bd 1' \\\n \"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n\nDoes that mean diffconflicts shouldn't be listed either?\n\nOf course not; just add vimdiff2.\n\nCheers.\n\n[1] https://lore.kernel.org/git/5fdd4f22c473b_1d952220844@natae.notmuch/\n[2] http://blog.plasticscm.com/2011/09/merge-recursive-strategy.html\n\n-- \nFelipe Contreras\n"},{"id":"412782","messageId":"CAJDDKr6LrBMyfdp5Tutp29W9OqhbW4ffcP5e6PD8ruyxk3rQxA@mail.gmail.com","threadId":"54839","inReplyTo":"20201221073633.GA157132@ellen","subject":"Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2020-12-21T22:15:17Z","receivedAt":"2020-12-21T22:16:52Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, Dec 20, 2020 at 11:36 PM Seth House wrote:\n>\n> On Sun, Dec 20, 2020 at 11:34:24PM -0600, Felipe Contreras wrote:\n> > I disagree. It's fine if you don't want to participate, but the fact\n> > remains that the position that some tools would want to turn this off\n> > hasn't been properly defended.\n>\n> If you are _genuinely_ interested in the answer to this question, please\n> read the section in my post titled \"Conflict Resolution\" followed by the\n> sub-section \"Custom Merge Algorithm\", and finally \"Merge algorithms\" [1]\n> on Wikipedia. Then pretend you want to write your own conflict\n> resolution algorithm for a new mergetool you've been dreaming up and ask\n> yourself what versions of the conflicted file your tool will need.\n>\n> [1] https://en.wikipedia.org/wiki/Merge_(version_control)#Merge_algorithms\n>\n> Right now the algorithm Git uses is pretty best-in-class so it might\n> seem unlikely that someone would want to write one of those. However\n> a whopping *seven* of the tools surveyed do just that. Some of them even\n> do a pretty good job (I've tried to point those out in the reviews).\n> You're preoccupied with identifying a specific \"adverse effect\" but this\n> debate isn't about that -- it's about giving individual tools the option\n> to choose how they are used. If people out there want to try and write\n> a better algorithm than Git, I want to see them try.\n>\n> That's the point I've been trying to drive home and that's the point\n> that David also made in his last reply to you.\n>\n> On that note: you replied to David and said:\n>\n> > [Y]ou spend your time implementing this on top of my patch. That way\n> > it's clear who made the mistake.\n>\n> I plan to start work on exactly that tomorrow. You made the initial\n> patch so if you'd prefer to take it over the finish line yourself I'll\n> defer. But if you're not interested then I would be happy to credit you\n> and finish it.\n\nThanks Seth, I think your plan of action sounds pretty solid to me.\n\nI'll be happy to review your patch. Just a heads-up that Felipe has a\nhistory on this list of creating long, never-ending, pointless rant\nthreads so sometimes the best course of action is to ignore him.\n\nciao,\nDavid\n"},{"id":"412790","messageId":"5fe134eeaec71_11498208f9@natae.notmuch","threadId":"54839","inReplyTo":"CAJDDKr6LrBMyfdp5Tutp29W9OqhbW4ffcP5e6PD8ruyxk3rQxA@mail.gmail.com","subject":"Code of conduct violation?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-21T23:51:10Z","receivedAt":"2020-12-21T23:51:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Aguilar wrote:\n> Just a heads-up that Felipe has a history on this list of creating\n> long, never-ending, pointless rant threads so sometimes the best\n> course of action is to ignore him.\n\nI think this can be considered a personal attack, which goes against the\ncode of conduct.\n\nThe code of conduct suggests behavior like:\n\n * Being respectful of differing viewpoints and experiences\n * Showing empathy towards other community members\n\nIt seems to me the above comment is an example of the opposite.\n\nIf you feel that my feedback is pointless, then don't engage with it.\nThere's no need to put aggravating labels, especially on a public\nsetting. Even if most people agree with you.\n\nI tolerate your opinion, but it's just that; an opinion.\n\nI think you should treat it as such (an opinion), and not blatantly\ndisregard the viewpoints of people you disagree with, and worse;\npublicly suggest others do the same.\n\nThe Git project engages in outreach programs precisely to increase the\ndiversity of the project, and this interest should not exclude diversity\nof thought. Seems counterproductive to allow these kinds of attacks\nagainst a minority opinion. It is in fact the minority opinion that\nneeds protection, the majority opinion can defend itself.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412845","messageId":"xmqqv9cuia8v.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe134eeaec71_11498208f9@natae.notmuch","subject":"Re: Code of conduct violation?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-22T07:13:36Z","receivedAt":"2020-12-22T07:14:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> David Aguilar wrote:\n>> Just a heads-up that Felipe has a history on this list of creating\n>> long, never-ending, pointless rant threads so sometimes the best\n>> course of action is to ignore him.\n>\n> I think this can be considered a personal attack, which goes against the\n> code of conduct.\n\nA PLC member here.\n\nAs CoC document outlines in its Enforcement section, the project\nleadership committee will review complaints of this kind, and may\nissue a statement later, but we do not encourage list participants\nto hold People's court publicly on the matter.\n\nThanks.\n\n"},{"id":"412846","messageId":"5fe1c3319a9ee_147e42083c@natae.notmuch","threadId":"54839","inReplyTo":"xmqqv9cuia8v.fsf@gitster.c.googlers.com","subject":"Re: Code of conduct violation?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-22T09:58:09Z","receivedAt":"2020-12-22T09:59:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > David Aguilar wrote:\n> >> Just a heads-up that Felipe has a history on this list of creating\n> >> long, never-ending, pointless rant threads so sometimes the best\n> >> course of action is to ignore him.\n> >\n> > I think this can be considered a personal attack, which goes against the\n> > code of conduct.\n> \n> A PLC member here.\n> \n> As CoC document outlines in its Enforcement section, the project\n> leadership committee will review complaints of this kind, and may\n> issue a statement later, but we do not encourage list participants\n> to hold People's court publicly on the matter.\n\nThat's fine.\n\nIn real life courts don't have to be open, but accusations and decisions\ndo.\n\nThe public is supposed to learn which sort of behavior is acceptable, and\nwhich not, from the behavior of others, and past decisions. In fact it's\nfrom examples that most people learn the rules, including future judges.\n\n-- \nFelipe Contreras\n"},{"id":"412848","messageId":"20201222150124.mnfcyofm4qyvvj4n@yadavpratyush.com","threadId":"54839","inReplyTo":"5fe134eeaec71_11498208f9@natae.notmuch","subject":"Re: Code of conduct violation?","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-12-22T15:01:24Z","receivedAt":"2020-12-22T15:02:12Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"Hi Felipe,\n\nOn 21/12/20 05:51PM, Felipe Contreras wrote:\n> David Aguilar wrote:\n> > Just a heads-up that Felipe has a history on this list of creating\n> > long, never-ending, pointless rant threads so sometimes the best\n> > course of action is to ignore him.\n\nWhile calling someone out like this is not the right thing at all, it is \na good opportunity for some introspection. I do not participate in the \nthreads you do so I can't say much about these \"never-ending, pointless \nrant threads\". But if enough people feel this way, maybe you need to \ndial it down a bit. The community needs to do its part in making you and \neveryone else feel welcome. At the same time you need to do your part in \nmaking contributors, especially the new ones, feel welcome and \nappreciated. Being overly critical can turn developers away from the \nproject.\n\nAnyway, those are my 2 cents. Do with them what you will.\n \n> I think this can be considered a personal attack, which goes against the\n> code of conduct.\n> \n> The code of conduct suggests behavior like:\n> \n> * Being respectful of differing viewpoints and experiences\n> * Showing empathy towards other community members\n> \n> It seems to me the above comment is an example of the opposite.\n> \n> If you feel that my feedback is pointless, then don't engage with it.\n> There's no need to put aggravating labels, especially on a public\n> setting. Even if most people agree with you.\n> \n> I tolerate your opinion, but it's just that; an opinion.\n> \n> I think you should treat it as such (an opinion), and not blatantly\n> disregard the viewpoints of people you disagree with, and worse;\n> publicly suggest others do the same.\n> \n> The Git project engages in outreach programs precisely to increase the\n> diversity of the project, and this interest should not exclude diversity\n> of thought. Seems counterproductive to allow these kinds of attacks\n> against a minority opinion. It is in fact the minority opinion that\n> needs protection, the majority opinion can defend itself.\n> \n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"412905","messageId":"5fe2c64bd3790_17f6720897@natae.notmuch","threadId":"54839","inReplyTo":"20201222150124.mnfcyofm4qyvvj4n@yadavpratyush.com","subject":"Re: Code of conduct violation?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-23T04:23:39Z","receivedAt":"2020-12-23T04:24:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Pratyush Yadav wrote:\n> While calling someone out like this is not the right thing at all, it is \n> a good opportunity for some introspection. I do not participate in the \n> threads you do so I can't say much about these \"never-ending, pointless \n> rant threads\". But if enough people feel this way, maybe you need to \n> dial it down a bit.\n\nDial what down a bit?\n\nMy opinion is my opinion.\n\nIf they want to discuss my opinion, then we can do so.\n\nIf they don't want to discuss my opinion, they can agree to disagree.\n\nBut I'm not going to pretend I'm fine with a change I disagree with; I'm\nnot. Especially when nobody is paying me to do this.\n\n> The community needs to do its part in making you and everyone else\n> feel welcome. At the same time you need to do your part in making\n> contributors, especially the new ones, feel welcome and appreciated.\n> Being overly critical can turn developers away from the project.\n\nWho are you talking about? I'm the one who made the contribution.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"412909","messageId":"xmqq5z4tdsiz.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe2c64bd3790_17f6720897@natae.notmuch","subject":"Re: Code of conduct violation?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-23T05:02:12Z","receivedAt":"2020-12-23T05:02:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Pratyush Yadav wrote:\n> ...\n> But I'm not going to pretend I'm fine with a change I disagree with; I'm\n> not. Especially when nobody is paying me to do this.\n\nI presume that at this point you are no longer talking about the\ninappropriateness of the phrase \"never-ending pointless rant\".\nPerhaps it is time to change the subject line.\n\nIf you still are, then please disregard the rest of the message.\n\n>> The community needs to do its part in making you and everyone else\n>> feel welcome. At the same time you need to do your part in making\n>> contributors, especially the new ones, feel welcome and appreciated.\n>> Being overly critical can turn developers away from the project.\n>\n> Who are you talking about? I'm the one who made the contribution.\n\nWhat does the \"change you disagree with\" you mention above refer to?\nChanges suggested by reviewers to add per-tool knob?\n"},{"id":"412910","messageId":"5fe2d89c212e8_18dc12083e@natae.notmuch","threadId":"54839","inReplyTo":"xmqq5z4tdsiz.fsf@gitster.c.googlers.com","subject":"Re: Code of conduct violation?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-23T05:41:48Z","receivedAt":"2020-12-23T05:42:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Pratyush Yadav wrote:\n> > ...\n> > But I'm not going to pretend I'm fine with a change I disagree with; I'm\n> > not. Especially when nobody is paying me to do this.\n> \n> I presume that at this point you are no longer talking about the\n> inappropriateness of the phrase \"never-ending pointless rant\".\n> Perhaps it is time to change the subject line.\n\nI am responding to what Pratyush said, and he didn't change the subject\nline.\n\nI don't know what he meant by \"it\". I'm just guessing.\n\n> If you still are, then please disregard the rest of the message.\n> \n> >> The community needs to do its part in making you and everyone else\n> >> feel welcome. At the same time you need to do your part in making\n> >> contributors, especially the new ones, feel welcome and appreciated.\n> >> Being overly critical can turn developers away from the project.\n> >\n> > Who are you talking about? I'm the one who made the contribution.\n> \n> What does the \"change you disagree with\" you mention above refer to?\n> Changes suggested by reviewers to add per-tool knob?\n\nYes.\n\n-- \nFelipe Contreras\n"},{"id":"412936","messageId":"xmqqzh248sy0.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe2d89c212e8_18dc12083e@natae.notmuch","subject":"Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-23T15:04:23Z","receivedAt":"2020-12-23T15:05:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> > But I'm not going to pretend I'm fine with a change I disagree with; I'm\n>> > not. Especially when nobody is paying me to do this.\n>> ...\n>> >> The community needs to do its part in making you and everyone else\n>> >> feel welcome. At the same time you need to do your part in making\n>> >> contributors, especially the new ones, feel welcome and appreciated.\n>> >> Being overly critical can turn developers away from the project.\n>> >\n>> > Who are you talking about? I'm the one who made the contribution.\n>> \n>> What does the \"change you disagree with\" you mention above refer to?\n>> Changes suggested by reviewers to add per-tool knob?\n>\n> Yes.\n\nIf so, please realize that this is a team effort. You are not THE\none making contribution. Everybody else also is. You are building\non top of others' code, others are helping you to improve your\npatches with their input, and others can and will later build on top\nof what you have done.\n\nIf you are not fine with a change others will make on top of what\nyou did, well, tough. It's not like by sending a patch you lick a\ncorner of the cake and make it untouchable by others.\n\nJust as you said, you can agree to disagree and move on. Once a\nrough concensus is reached that the work on top of what you did is a\ngood direction to go, it would not get us anywhere to repeat the\nsame opinion over and over again to block it.\n\n"},{"id":"412938","messageId":"5fe36790793ae_2354120839@natae.notmuch","threadId":"54839","inReplyTo":"xmqqzh248sy0.fsf@gitster.c.googlers.com","subject":"RE: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-23T15:51:44Z","receivedAt":"2020-12-23T15:52:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> > But I'm not going to pretend I'm fine with a change I disagree with; I'm\n> >> > not. Especially when nobody is paying me to do this.\n> >> ...\n> >> >> The community needs to do its part in making you and everyone else\n> >> >> feel welcome. At the same time you need to do your part in making\n> >> >> contributors, especially the new ones, feel welcome and appreciated.\n> >> >> Being overly critical can turn developers away from the project.\n> >> >\n> >> > Who are you talking about? I'm the one who made the contribution.\n> >> \n> >> What does the \"change you disagree with\" you mention above refer to?\n> >> Changes suggested by reviewers to add per-tool knob?\n> >\n> > Yes.\n> \n> If so, please realize that this is a team effort.\n\nYes, but different people in a team have different roles. There's the\nmaintainers, the contributors, the reviewers, the translators, etc.\n\n> You are not THE one making contribution.\n\nWhen I'm sending a patch, I have the role of \"contributor\".\n\nThat doesn't mean the people revieweing the patch aren't making a\ncontribution as well, but traditionally they are not the ones being\nassigned the role of \"contributor\".\n\nIn your own release notes [1] you say:\n\n New contributors whose contributions weren't in v2.29.0 are as\n follows.\n\nPresumably these are the people who contributed patches, not reviews.\n\n> If you are not fine with a change others will make on top of what\n> you did, well, tough.\n\nYes, I know.\n\nI don't know why you feel the need to explain that to me. I have been\ncontributing to open source projects for more than 20 years.\n\n> It's not like by sending a patch you lick a corner of the cake and\n> make it untouchable by others.\n\nNo, but just because others have an opinion that doesn't mean I must\nhave the same opinion as others.\n\nTake judicial panels as an analogy. A group of judges must arrive at an\nopinion [2], and sometimes they do without problems; all of them agree,\nwhich is called an \"unanimous opinion\". Sometimes not everyone agrees,\nin which case it's called a \"majority opinion\". When not everyone\nagrees, a judge is perfectly entitled to write his or her \"dissenting\nopinion\", which is a disagreement with the \"majority opinion\".\n\nWhen there's a dissenting opinion, the court still moves forward with\nthe majority opinion, the dissenting opinion is written down for the\nrecord.\n\nWhen I express my dissenting opinion I'm not saying nobody should write\na patch on top of mine. Of course they can. Anybody can take my code and\ndo whatever they want with it (as long as they don't violate the license\nof the project).\n\nWhat they cannot do is add my Signed-off-by line to code I don't agree\nwith.\n\n> Just as you said, you can agree to disagree and move on.\n\nYes, with my disagreement stated for the record. Just like dissenting\nopinions in judicial panels.\n\n> Once a rough concensus is reached that the work on top of what you did\n> is a good direction to go, it would not get us anywhere to repeat the\n> same opinion over and over again to block it.\n\nI am not repeating the same opinion over and over, I am responding to\nthe comments of others, with an argument they fail to address.\n\nIf person A doesn't address my argument, and person B doesn't address my\nargument, and person C comes along with comments that warrant the repeat\nof the argument; I'm going to repeat the argument.\n\nNobody has addressed the argument.\n\nIt is the fault of person A that didn't address my argument that I had\nto repeat it to person B, and so on. Not mine.\n\nCheers.\n\n[1] https://lore.kernel.org/git/xmqqsg82qur4.fsf@gitster.c.googlers.com/\n[2] https://en.wikipedia.org/wiki/Judicial_opinion#Kinds_of_judicial_opinions\n\n-- \nFelipe Contreras\n"},{"id":"412949","messageId":"xmqqpn306y3a.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe36790793ae_2354120839@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-23T20:56:09Z","receivedAt":"2020-12-23T20:57:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> You are not THE one making contribution.\n>\n> When I'm sending a patch, I have the role of \"contributor\".\n\nYes, you are a contributor, but there are other contributors to the\nchange under discussion.\n\n> In your own release notes [1] you say:\n>\n> New contributors whose contributions weren't in v2.29.0 are as\n> follows.\n>\n> Presumably these are the people who contributed patches, not reviews.\n\nIf I said \"These community members have their name as an author of a\npatch for the first time since v2.29\", would that mean those who do\nnot have any commit under their name are not community members?\n\n> I don't know why you feel the need to explain that to me. I have been\n> contributing to open source projects for more than 20 years.\n\nBecause you are acting as if you don't know and have to always be\nthe right one no matter what. You may not mean to do so, but that\nis how your behaviour appears to me (note that I did not know say\n\"to others\").\n\nI won't have time to respond to your word games after I send this\nmessage.\n"},{"id":"412976","messageId":"5fe3ea5eb3f5b_7855a208c6@natae.notmuch","threadId":"54839","inReplyTo":"xmqqpn306y3a.fsf@gitster.c.googlers.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-24T01:09:50Z","receivedAt":"2020-12-24T01:11:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> You are not THE one making contribution.\n> >\n> > When I'm sending a patch, I have the role of \"contributor\".\n> \n> Yes, you are a contributor, but there are other contributors to the\n> change under discussion.\n\nThere are other people _contributing_, but typically they are not\nassigned the role of _contributor_.\n\nThis has been my experience in all the open source projects I've worked\non.\n\nMy guess is that semantically the role of contributor is different\nbecause they are the ones bearing the brunt of the work (thinking the\nidea, coding, testing, cleaning, sending the patch, addressing comments,\nre-coding, re-testing, re-cleaing, sending another patch... etc).\n\nOf course everyone contributes, but in any given patch series, the\n\"contributor\" contributes the most.\n\n> > In your own release notes [1] you say:\n> >\n> > New contributors whose contributions weren't in v2.29.0 are as\n> > follows.\n> >\n> > Presumably these are the people who contributed patches, not reviews.\n> \n> If I said \"These community members have their name as an author of a\n> patch for the first time since v2.29\", would that mean those who do\n> not have any commit under their name are not community members?\n\nNo. It would just mean they had other roles (not contributor).\n\nFor example, when a company pays their employees to contribute to the\nproject, the company can be considered a contributor (e.g. Google).\n\n> > I don't know why you feel the need to explain that to me. I have been\n> > contributing to open source projects for more than 20 years.\n> \n> Because you are acting as if you don't know and have to always be\n> the right one no matter what. You may not mean to do so, but that\n> is how your behaviour appears to me (note that I did not know say\n> \"to others\").\n\nYes, but you do not read minds, and you can't know what is happening\ninside mine.\n\nAttempting to do so is usually not a good idea [1].\n\n> I won't have time to respond to your word games after I send this\n> message.\n\nWords are the only tool we have to communicate among minds.\n\nThere's a reason why linguistics is an entire field of study; some\npeople are trying to really understand what other people are really\ntrying to say.\n\nI for one don't understand why you would change the subject of the\nthread to \"Nobody is THE one making contribution\", and then not be\ninterested in understanding what others understand by the word\n\"contribution\".\n\nBut I'm not going to read into it something you didn't attempt to say.\n\nI don't read minds.\n\nCheers.\n\n[1] https://cogbtherapy.com/cbt-blog/common-cognitive-distortions-mind-reading\n\n-- \nFelipe Contreras\n"},{"id":"412978","messageId":"87r1ngufmf.fsf@evledraar.gmail.com","threadId":"54839","inReplyTo":"5fe36790793ae_2354120839@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2020-12-24T02:01:12Z","receivedAt":"2020-12-24T02:02:12Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Dec 23 2020, Felipe Contreras wrote:\n\n> When I express my dissenting opinion I'm not saying nobody should write\n> a patch on top of mine. Of course they can. Anybody can take my code and\n> do whatever they want with it (as long as they don't violate the license\n> of the project).\n>\n> What they cannot do is add my Signed-off-by line to code I don't agree\n> with.\n\nI don't think that's what Signed-off-by means, per SubmittingPatches:\n\n To improve tracking of who did what, we ask you to certify that you\n wrote the patch or have the right to pass it on under the same\n license as ours, by \"signing off\" your patch[...under the DCO:\n https://developercertificate.org/]\n\nSo I find this rather unlikely, but let's say I author a patch for\ngit.git and send it to this ML with a Signed-off-by.\n\nIf someone else then takes that patch and changes it in a way that I\nvehemently disagree with and gets Junio to accept it into git.git in its\naltered form, that altered patch should still carry my Signed-off-by, as\nwell as that of whoever altered it.\n\nBecause it's a trailer for maintaining the licensing paper trail. It\ndoesn't mean \"Ævar thinks this patch as it stands is a good idea\"[1].\n\n\"No Discrimination Against Fields of Endeavor\" is an integral part of\nfree software & open source. In our case it means that when you\ncontribute code under our COPYING terms someone else might use in a way\nyou don't approve of.\n\nE.g. I'm sure that arms contractors, totalitarian regimes etc. or other\nentities some might disapprove of are using git in some way.\n\nThat non-restriction on fields of endeavor also extends to individual\npatches licensed under a free software license & the necessity to\nmaintain a paper trail about who their authors are and if they certified\nthem under the DCO.\n\n1. As an aside, I haven't needed involvement from others to later\n realize that an integrated patch of mine with my SOB maybe wasn't\n such a good idea after all :)\n"},{"id":"412983","messageId":"5fe424d0528a2_7855a208d3@natae.notmuch","threadId":"54839","inReplyTo":"87r1ngufmf.fsf@evledraar.gmail.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-24T05:19:12Z","receivedAt":"2020-12-24T05:26:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Wed, Dec 23 2020, Felipe Contreras wrote:\n> \n> > When I express my dissenting opinion I'm not saying nobody should write\n> > a patch on top of mine. Of course they can. Anybody can take my code and\n> > do whatever they want with it (as long as they don't violate the license\n> > of the project).\n> >\n> > What they cannot do is add my Signed-off-by line to code I don't agree\n> > with.\n> \n> I don't think that's what Signed-off-by means, per SubmittingPatches:\n> \n> To improve tracking of who did what, we ask you to certify that you\n> wrote the patch or have the right to pass it on under the same\n> license as ours, by \"signing off\" your patch[...under the DCO:\n> https://developercertificate.org/]\n\nYes, but the DCO requires (d):\n\n d. I understand and agree that this project and the contribution are\n public and that a record of the contribution (including all personal\n information I submit with it, including my sign-off) is maintained\n indefinitely and may be redistributed consistent with this project or\n the open source license(s) involved.\n\nWe can narrow down the part I'm talking about:\n\n d. I *agree* that a record of the contribution is maintained\n indefinitely.\n\nI don't agree with that.\n\nMoreover, the relevant definition of \"sign off\" in English in my opinion\nis [1]:\n\n to approve or acknowledge something by or as if by a signature (sign\n off on a memo)\n\nIf I didn't put my \"signature\" in a commit, then it's not signed off by\nme.\n\n> So I find this rather unlikely, but let's say I author a patch for\n> git.git and send it to this ML with a Signed-off-by.\n> \n> If someone else then takes that patch and changes it in a way that I\n> vehemently disagree with and gets Junio to accept it into git.git in its\n> altered form, that altered patch should still carry my Signed-off-by, as\n> well as that of whoever altered it.\n\nI don't think so.\n\nEven if you disregard clause (d) of the DCO, in English you didn't \"sign\noff\" on that particular version of the patch.\n\n> \"No Discrimination Against Fields of Endeavor\" is an integral part of\n> free software & open source. In our case it means that when you\n> contribute code under our COPYING terms someone else might use in a way\n> you don't approve of.\n\nYes, you just have to make the record straight; do your changes in a\nseparate commit without my \"sign off\".\n\n> E.g. I'm sure that arms contractors, totalitarian regimes etc. or other\n> entities some might disapprove of are using git in some way.\n\nYes, and you can modify my patch and keep my s-o-b, I'm not going to sue\nyou.\n\nI just don't think that's right.\n\n> That non-restriction on fields of endeavor also extends to individual\n> patches licensed under a free software license & the necessity to\n> maintain a paper trail about who their authors are and if they certified\n> them under the DCO.\n\nSure, so if you need to keep a paper trail about the copyright of the\ncode, why would you risk that simply because the author didn't agree on\nthe further changes.\n\nJust do them on a separate commit. Problem solved.\n\n> 1. As an aside, I haven't needed involvement from others to later\n> realize that an integrated patch of mine with my SOB maybe wasn't\n> such a good idea after all :)\n\nOh, me neither. But in this particular case I'm sure X is wrong, so I'm\nstating unequivocally that I think X is wrong.\n\nPlus, in my experience I usually think X is the case, and it's not only\nafter I roll up my sleeves and get my hands dirty that I realize what's\nactually the case.\n\nChanging your mind after you get your hands dirty is usually a good\nthing. Which is another reason why I like Linus Torvalds' phrase: \"talk\nis cheap, show me the code\".\n\nCheers.\n\n[1] https://www.merriam-webster.com/dictionary/sign%20off\n\n-- \nFelipe Contreras"},{"id":"412995","messageId":"87o8ijv124.fsf@evledraar.gmail.com","threadId":"54839","inReplyTo":"5fe424d0528a2_7855a208d3@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2020-12-24T12:30:27Z","receivedAt":"2020-12-24T12:31:23Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Dec 24 2020, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Wed, Dec 23 2020, Felipe Contreras wrote:\n>> \n>> > When I express my dissenting opinion I'm not saying nobody should write\n>> > a patch on top of mine. Of course they can. Anybody can take my code and\n>> > do whatever they want with it (as long as they don't violate the license\n>> > of the project).\n>> >\n>> > What they cannot do is add my Signed-off-by line to code I don't agree\n>> > with.\n>> \n>> I don't think that's what Signed-off-by means, per SubmittingPatches:\n>> \n>> To improve tracking of who did what, we ask you to certify that you\n>> wrote the patch or have the right to pass it on under the same\n>> license as ours, by \"signing off\" your patch[...under the DCO:\n>> https://developercertificate.org/]\n>\n> Yes, but the DCO requires (d):\n>\n> d. I understand and agree that this project and the contribution are\n> public and that a record of the contribution (including all personal\n> information I submit with it, including my sign-off) is maintained\n> indefinitely and may be redistributed consistent with this project or\n> the open source license(s) involved.\n>\n> We can narrow down the part I'm talking about:\n>\n> d. I *agree* that a record of the contribution is maintained\n> indefinitely.\n>\n> I don't agree with that.\n\nI don't understand you here. You don't agree that we retain\nSigned-off-by lines indefinitely, or just in the case of amended\npatches?\n\n> Moreover, the relevant definition of \"sign off\" in English in my opinion\n> is [1]:\n>\n> to approve or acknowledge something by or as if by a signature (sign\n> off on a memo)\n>\n> If I didn't put my \"signature\" in a commit, then it's not signed off by\n> me.\n\nI think this use of 'signed off\" makes perfect sense if you interpret\nthe sign-off to mean \"I signed off on the copyright eligibility of this\nwork for inclusion\" which is what I think it means.\n\nNot \"I signed off on my subjective approval of this patch & what it's\nfor etc.\", which seems to be closer to your interpretation.\n\n>> So I find this rather unlikely, but let's say I author a patch for\n>> git.git and send it to this ML with a Signed-off-by.\n>> \n>> If someone else then takes that patch and changes it in a way that I\n>> vehemently disagree with and gets Junio to accept it into git.git in its\n>> altered form, that altered patch should still carry my Signed-off-by, as\n>> well as that of whoever altered it.\n>\n> I don't think so.\n>\n> Even if you disregard clause (d) of the DCO, in English you didn't \"sign\n> off\" on that particular version of the patch.\n\n[...addressed below...]\n\n>> \"No Discrimination Against Fields of Endeavor\" is an integral part of\n>> free software & open source. In our case it means that when you\n>> contribute code under our COPYING terms someone else might use in a way\n>> you don't approve of.\n>\n> Yes, you just have to make the record straight; do your changes in a\n> separate commit without my \"sign off\".\n\nWe like to maintain \"make test\" passing for every commit, and sometimes\nwe have patches on the ML with a SOB that don't even compile yet, let\nalone pass tests, because they were provided by their authors as \"maybe\ntry this\" or other near-pseudocode.\n\nWe also like to optimize patch order/size/splits/etc. for the benefit of\nreviewers. Sometimes someone might send a patch with a SOB that's better\nsquashed into another one, or refactored into N commits spread across a\nseries etc.\n\n>> E.g. I'm sure that arms contractors, totalitarian regimes etc. or other\n>> entities some might disapprove of are using git in some way.\n>\n> Yes, and you can modify my patch and keep my s-o-b, I'm not going to sue\n> you.\n>\n> I just don't think that's right.\n>\n>> That non-restriction on fields of endeavor also extends to individual\n>> patches licensed under a free software license & the necessity to\n>> maintain a paper trail about who their authors are and if they certified\n>> them under the DCO.\n>\n> Sure, so if you need to keep a paper trail about the copyright of the\n> code, why would you risk that simply because the author didn't agree on\n> the further changes.\n>\n> Just do them on a separate commit. Problem solved.\n\nI don't understand how the copyright paper trail is at risk just because\nwe combine N patches into one.\n\nThe important part is that we have a declaration that the sum of the\nwork (and whatever it's derived from) is properly licensed, that the\nauthors had the right to license it for inclusion etc.\n"},{"id":"412999","messageId":"00f401d6da06$be415560$3ac40020$@nexbridge.com","threadId":"54839","inReplyTo":"5fe424d0528a2_7855a208d3@natae.notmuch","subject":"RE: Nobody is THE one making contribution","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2020-12-24T15:09:09Z","receivedAt":"2020-12-24T15:10:03Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 24, 2020 12:19 AM, Felipe Contreras wrote:\n> To: Ævar Arnfjörð Bjarmason ; Felipe Contreras\n> \n> Cc: Junio C Hamano ; Pratyush Yadav\n> ; David Aguilar ; Seth House\n> ; Git Mailing List ; Christian Couder\n> ; git@sfconservancy.org\n> Subject: Re: Nobody is THE one making contribution\n> \n> Ævar Arnfjörð Bjarmason wrote:\n> > On Wed, Dec 23 2020, Felipe Contreras wrote:\n> >\n> > > When I express my dissenting opinion I'm not saying nobody should\n> > > write a patch on top of mine. Of course they can. Anybody can take\n> > > my code and do whatever they want with it (as long as they don't\n> > > violate the license of the project).\n> > >\n> > > What they cannot do is add my Signed-off-by line to code I don't\n> > > agree with.\n> >\n> > I don't think that's what Signed-off-by means, per SubmittingPatches:\n> >\n> > To improve tracking of who did what, we ask you to certify that you\n> > wrote the patch or have the right to pass it on under the same\n> > license as ours, by \"signing off\" your patch[...under the DCO:\n> > https://developercertificate.org/]\n> \n> Yes, but the DCO requires (d):\n> \n> d. I understand and agree that this project and the contribution are\n> public and that a record of the contribution (including all personal\n> information I submit with it, including my sign-off) is maintained\n> indefinitely and may be redistributed consistent with this project or\n> the open source license(s) involved.\n> \n> We can narrow down the part I'm talking about:\n> \n> d. I *agree* that a record of the contribution is maintained\n> indefinitely.\n> \n> I don't agree with that.\n\nClause d is important to maintain compatibility with GRPD[1] rules about maintaining identifying information. This clause is more than about the contribution. It is about consent to maintain your name and email on record indefinitely, as part of the contribution, in the git repository, without the ability to rescind the permission at some point in the future.\n\nSincerely,\nRandall\n\n[1] https://eur-lex.europa.eu/eli/reg/2016/679/oj\n\n\n\n"},{"id":"413001","messageId":"5fe4b33dbc028_19c920834@natae.notmuch","threadId":"54839","inReplyTo":"87o8ijv124.fsf@evledraar.gmail.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-24T15:26:53Z","receivedAt":"2020-12-24T15:27:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Dec 24 2020, Felipe Contreras wrote:\n> \n> > Ævar Arnfjörð Bjarmason wrote:\n> >> On Wed, Dec 23 2020, Felipe Contreras wrote:\n> >> \n> >> > When I express my dissenting opinion I'm not saying nobody should write\n> >> > a patch on top of mine. Of course they can. Anybody can take my code and\n> >> > do whatever they want with it (as long as they don't violate the license\n> >> > of the project).\n> >> >\n> >> > What they cannot do is add my Signed-off-by line to code I don't agree\n> >> > with.\n> >> \n> >> I don't think that's what Signed-off-by means, per SubmittingPatches:\n> >> \n> >> To improve tracking of who did what, we ask you to certify that you\n> >> wrote the patch or have the right to pass it on under the same\n> >> license as ours, by \"signing off\" your patch[...under the DCO:\n> >> https://developercertificate.org/]\n> >\n> > Yes, but the DCO requires (d):\n> >\n> > d. I understand and agree that this project and the contribution are\n> > public and that a record of the contribution (including all personal\n> > information I submit with it, including my sign-off) is maintained\n> > indefinitely and may be redistributed consistent with this project or\n> > the open source license(s) involved.\n> >\n> > We can narrow down the part I'm talking about:\n> >\n> > d. I *agree* that a record of the contribution is maintained\n> > indefinitely.\n> >\n> > I don't agree with that.\n> \n> I don't understand you here. You don't agree that we retain\n> Signed-off-by lines indefinitely, or just in the case of amended\n> patches?\n\nThe DCO requires that I agree that a record of my contribution is\nmaintained indefinitely.\n\nIf I don't agree that a record of a particular contribution is\nmaintained indefinitely, the DCO says you shouldn't use it.\n\n> > Moreover, the relevant definition of \"sign off\" in English in my opinion\n> > is [1]:\n> >\n> > to approve or acknowledge something by or as if by a signature (sign\n> > off on a memo)\n> >\n> > If I didn't put my \"signature\" in a commit, then it's not signed off by\n> > me.\n> \n> I think this use of 'signed off\" makes perfect sense if you interpret\n> the sign-off to mean \"I signed off on the copyright eligibility of this\n> work for inclusion\" which is what I think it means.\n> \n> Not \"I signed off on my subjective approval of this patch & what it's\n> for etc.\", which seems to be closer to your interpretation.\n\nWhy does it have to be only one meaning?\n\nJunio doesn't sign off on a patch that he doesn't think is good.\n\nSame happens with all the lieutenants of Linux.\n\n> >> \"No Discrimination Against Fields of Endeavor\" is an integral part of\n> >> free software & open source. In our case it means that when you\n> >> contribute code under our COPYING terms someone else might use in a way\n> >> you don't approve of.\n> >\n> > Yes, you just have to make the record straight; do your changes in a\n> > separate commit without my \"sign off\".\n> \n> We like to maintain \"make test\" passing for every commit, and sometimes\n> we have patches on the ML with a SOB that don't even compile yet, let\n> alone pass tests, because they were provided by their authors as \"maybe\n> try this\" or other near-pseudocode.\n> \n> We also like to optimize patch order/size/splits/etc. for the benefit of\n> reviewers. Sometimes someone might send a patch with a SOB that's better\n> squashed into another one, or refactored into N commits spread across a\n> series etc.\n\nYes. And most of the time that's fine, because the original author is\nnot objecting to the clause (d).\n\n> >> E.g. I'm sure that arms contractors, totalitarian regimes etc. or other\n> >> entities some might disapprove of are using git in some way.\n> >\n> > Yes, and you can modify my patch and keep my s-o-b, I'm not going to sue\n> > you.\n> >\n> > I just don't think that's right.\n> >\n> >> That non-restriction on fields of endeavor also extends to individual\n> >> patches licensed under a free software license & the necessity to\n> >> maintain a paper trail about who their authors are and if they certified\n> >> them under the DCO.\n> >\n> > Sure, so if you need to keep a paper trail about the copyright of the\n> > code, why would you risk that simply because the author didn't agree on\n> > the further changes.\n> >\n> > Just do them on a separate commit. Problem solved.\n> \n> I don't understand how the copyright paper trail is at risk just because\n> we combine N patches into one.\n\nIt's not just a copyright paper trail, the DCO clearly states that the\nauthor should:\n\n d. I *agree* that a record of the contribution is maintained\n indefinitely.\n\n> The important part is that we have a declaration that the sum of the\n> work (and whatever it's derived from) is properly licensed, that the\n> authors had the right to license it for inclusion etc.\n\nThat's the important part, yes. It's not the only part.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"413002","messageId":"5fe4b5cbacf0d_19c92087f@natae.notmuch","threadId":"54839","inReplyTo":"00f401d6da06$be415560$3ac40020$@nexbridge.com","subject":"RE: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-24T15:37:47Z","receivedAt":"2020-12-24T15:38:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n> On December 24, 2020 12:19 AM, Felipe Contreras wrote:\n> > We can narrow down the part I'm talking about:\n> > \n> > d. I *agree* that a record of the contribution is maintained\n> > indefinitely.\n> > \n> > I don't agree with that.\n> \n> Clause d is important to maintain compatibility with GRPD[1] rules\n> about maintaining identifying information. This clause is more than\n> about the contribution. It is about consent to maintain your name and\n> email on record indefinitely, as part of the contribution, in the git\n> repository, without the ability to rescind the permission at some\n> point in the future.\n\nI didn't mean I don't agree that clause (d) should be there.\n\nI mean if in a particular contribution I don't agree that a record of\nthe contribution is maintained indefinitely with my name, then clause\n(d) is not met. And it is not actually my true contribution, but a\nbastardization of it made by somebody else.\n\nYou shouldn't assign to my name changes I don't agree with in\nperpetuity.\n\n-- \nFelipe Contreras\n"},{"id":"413006","messageId":"CAJDDKr7bhnbr6NZfV28rJN5JrHkO+gZCLY_LkwiCxxBp=HWfbg@mail.gmail.com","threadId":"54839","inReplyTo":"5fe134eeaec71_11498208f9@natae.notmuch","subject":"Re: Code of conduct violation?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2020-12-24T21:00:45Z","receivedAt":"2020-12-24T21:05:29Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Dec 21, 2020 at 3:51 PM Felipe Contreras\n wrote:\n>\n> David Aguilar wrote:\n> > Just a heads-up that Felipe has a history on this list of creating\n> > long, never-ending, pointless rant threads so sometimes the best\n> > course of action is to ignore him.\n>\n> I think this can be considered a personal attack, which goes against the\n> code of conduct.\n\n\nSorry Felipe -- there is no explanation that will satisfy you and this\nis not the place to try and \"make a case\" for what was said. The\ndownsides of further engagement and messages that did not need to be\nexchanged has already played itself out.\n\nPlease take this apology so that you can have the last word. I am not\ngoing to try and convince anyone that my response was appropriate.\n\n\n\n> The code of conduct suggests behavior like:\n>\n> * Being respectful of differing viewpoints and experiences\n> * Showing empathy towards other community members\n>\n> It seems to me the above comment is an example of the opposite.\n>\n> If you feel that my feedback is pointless, then don't engage with it.\n> There's no need to put aggravating labels, especially on a public\n> setting. Even if most people agree with you.\n>\n> I tolerate your opinion, but it's just that; an opinion.\n>\n> I think you should treat it as such (an opinion), and not blatantly\n> disregard the viewpoints of people you disagree with, and worse;\n> publicly suggest others do the same.\n\n\nI could try and explain that being intolerant of my and others'\nviewpoints and dismissing them as being inadequately defended or\nnon-existent is ironic, but arguing is a pointless endeavor. I gave\nyou an honest, but inappropriate, response in public because being\nhonest and candid is a form of empathy, but that doesn't make it okay.\n\nI appreciate your talents and tenacity. I can't ask you to be less\nabrasive. I can't ask you to not ignore the opinions of others. All\nI can offer you is my respect and an apology.\n\nSorry for saying that.\n\nMuch respect to you Felipe. In respect for you, I will politely\nrefrain from responding to this thread.\n\nSometimes the best arguments are the ones that are not made.\n-- \nDavid\n"},{"id":"413008","messageId":"5fe516f29c37d_87ce208d2@natae.notmuch","threadId":"54839","inReplyTo":"CAJDDKr7bhnbr6NZfV28rJN5JrHkO+gZCLY_LkwiCxxBp=HWfbg@mail.gmail.com","subject":"Re: Code of conduct violation?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-24T22:32:18Z","receivedAt":"2020-12-24T22:33:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Aguilar wrote:\n> On Mon, Dec 21, 2020 at 3:51 PM Felipe Contreras\n> wrote:\n> >\n> > David Aguilar wrote:\n> > > Just a heads-up that Felipe has a history on this list of creating\n> > > long, never-ending, pointless rant threads so sometimes the best\n> > > course of action is to ignore him.\n> >\n> > I think this can be considered a personal attack, which goes against the\n> > code of conduct.\n> \n> Sorry Felipe -- there is no explanation that will satisfy you and this\n> is not the place to try and \"make a case\" for what was said.\n\nI'm not looking for an explanation from you. I'm just wondering if others\nconsider it a violation of the code of conduct.\n\n> > The code of conduct suggests behavior like:\n> >\n> > * Being respectful of differing viewpoints and experiences\n> > * Showing empathy towards other community members\n> >\n> > It seems to me the above comment is an example of the opposite.\n> >\n> > If you feel that my feedback is pointless, then don't engage with it.\n> > There's no need to put aggravating labels, especially on a public\n> > setting. Even if most people agree with you.\n> >\n> > I tolerate your opinion, but it's just that; an opinion.\n> >\n> > I think you should treat it as such (an opinion), and not blatantly\n> > disregard the viewpoints of people you disagree with, and worse;\n> > publicly suggest others do the same.\n> \n> I could try and explain that being intolerant of my and others'\n> viewpoints and dismissing them as being inadequately defended or\n> non-existent is ironic, but arguing is a pointless endeavor.\n\nI tolerate your viewpoint, at no point did I ever a attempt to silence\nyou, or urged others to ignore it.\n\nIn fact, I did the opposite; I engaged with you and replied to you more\nthan once [1] (you did not reply back).\n\nI welcome your viewpoint. I just disagree with it.\n\n> I gave you an honest, but inappropriate, response in public because\n> being honest and candid is a form of empathy, but that doesn't make it\n> okay.\n\nYour response was not addressed to me.\n\nI don't doubt your response was honest, I'm just think it was\ninnaproriate in a public forum. I'm glad you acknowledge that.\n\n> I appreciate your talents and tenacity. I can't ask you to be less\n> abrasive.\n\nThank you. Same goes from me.\n\n> I can't ask you to not ignore the opinions of others.\n\nOnce again: I did not ignore your opinion, my response is sill waiting\nyour response [1].\n\nYou are free to keep defending your opinion. In fact, I would appreciate\nso.\n\n> All I can offer you is my respect and an apology.\n> \n> Sorry for saying that.\n\nThank you. No hard feelings.\n\n> Much respect to you Felipe. In respect for you, I will politely\n> refrain from responding to this thread.\n> \n> Sometimes the best arguments are the ones that are not made.\n\nI think arguments should be stated aloud.\n\nI always welcome your arguments, and if you honestly think my point of\nview doesn't make sense, you are completely free to state so candidly.\nJust remember that I'm also entitled to have own opinion in disagreement\nof yours.\n\nBest wishes.\n\n[1] https://lore.kernel.org/git/5fdffe7f7fbd_89f120860@natae.notmuch/\n\n-- \nFelipe Contreras\n"},{"id":"413010","messageId":"xmqqy2hm25gh.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe4b5cbacf0d_19c92087f@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-24T22:40:30Z","receivedAt":"2020-12-24T22:41:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Randall S. Becker wrote:\n>> On December 24, 2020 12:19 AM, Felipe Contreras wrote:\n>> > We can narrow down the part I'm talking about:\n>> > \n>> > d. I *agree* that a record of the contribution is maintained\n>> > indefinitely.\n>> > \n>> > I don't agree with that.\n>> \n>> Clause d is important to maintain compatibility with GRPD[1] rules\n>> about maintaining identifying information. This clause is more than\n>> about the contribution. It is about consent to maintain your name and\n>> email on record indefinitely, as part of the contribution, in the git\n>> repository, without the ability to rescind the permission at some\n>> point in the future.\n>\n> I didn't mean I don't agree that clause (d) should be there.\n>\n> I mean if in a particular contribution I don't agree that a record of\n> the contribution is maintained indefinitely with my name, then clause\n> (d) is not met. And it is not actually my true contribution, but a\n> bastardization of it made by somebody else.\n>\n> You shouldn't assign to my name changes I don't agree with in\n> perpetuity.\n\nThe way I read our DCO, especially its part (b), is that it is very\nmuch designed to allow editing, tweaking and improving on others'\npatches with editor's sign-off while passing a patch around.\n\n\n"},{"id":"413012","messageId":"xmqqtusa24oa.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe4b33dbc028_19c920834@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-24T22:57:25Z","receivedAt":"2020-12-24T22:58:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> Not \"I signed off on my subjective approval of this patch & what it's\n>> for etc.\", which seems to be closer to your interpretation.\n>\n> Why does it have to be only one meaning?\n>\n> Junio doesn't sign off on a patch that he doesn't think is good.\n> Same happens with all the lieutenants of Linux.\n\nI know some people try to indicate that a patch is not ready for\ninclusion as-is by omitting sign-off. That way, it would not be\nenough for the maintainer to pick it up and add his or her own\nsign-off---the maintainer has to go back to the author and ask it to\nbe signed off (which happens).\n\nBut I try not to use the lack of sign-off on my patches to mean\nanything, because the technique does not work for me. A patch I\nsent without my sign-off may later turn out to be worth keeping, and\nwhen I run \"git am -s\" on it, I'd have a full sign-off chain anyway.\nThere is no \"going back to the author and ask\" necessary.\n\nIn any case, I am not sure what you are trying to achieve by\nmentioning the cases where patches are not signed-off.\n\nThe reason why some patches do not carry sign-off might be because\nthe sender does not wish to certify and that's OK. But if you are\narguing that when you write \"Signed-off-by:\" your sign-off can mean\nsomething other than what DCO says it means, what those people who\nsometimes do not sign-off their work do would not be useful at all\nto support your claim, I would have to say. You need to find other\npeople's signed-off patch when they did not mean to certify them\nunder DCO, if \"it does not have to be only one meaning\" is what you\nwant to support.\n"},{"id":"413026","messageId":"5fe8c464bc190_e22d2086a@natae.notmuch","threadId":"54839","inReplyTo":"xmqqtusa24oa.fsf@gitster.c.googlers.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-27T17:29:08Z","receivedAt":"2020-12-27T17:30:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> Not \"I signed off on my subjective approval of this patch & what it's\n> >> for etc.\", which seems to be closer to your interpretation.\n> >\n> > Why does it have to be only one meaning?\n> >\n> > Junio doesn't sign off on a patch that he doesn't think is good.\n> > Same happens with all the lieutenants of Linux.\n\n> The reason why some patches do not carry sign-off might be because\n> the sender does not wish to certify and that's OK.\n\nThat's one reason.\n\n> But if you are arguing that when you write \"Signed-off-by:\" your\n> sign-off can mean something other than what DCO says it means,\n\nThe DCO has clause (d), which clearly states the developer must agree\nthat a record of his/her contribution is maintained indefinitely (and\nthat includes his/her sign off).\n\nSo there's at least two meanings in the DCO itself.\n\nAdditionally, that's the meaning of the phrase \"sign off\" in English; I\napprove of this.\n\n-- \nFelipe Contreras\n"},{"id":"413028","messageId":"xmqq5z4nqey1.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe8c464bc190_e22d2086a@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-27T18:30:46Z","receivedAt":"2020-12-27T18:32:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> But if you are arguing that when you write \"Signed-off-by:\" your\n>> sign-off can mean something other than what DCO says it means,\n>\n> The DCO has clause (d), which clearly states the developer must agree\n> that a record of his/her contribution is maintained indefinitely (and\n> that includes his/her sign off).\n\nYes. Are you saying that you are OK with (a)-(c) but not (d)?\n\n> So there's at least two meanings in the DCO itself.\n\nI am not sure what you mean. DCO itself has a to d (four) clauses,\nso that is not where your two comes from (unless you are hedging by\nsaying \"at least two\"). What are you counting to reach two?\n\nStill puzzled.\n"},{"id":"413029","messageId":"5fe8d6bf1a1a3_f1c220893@natae.notmuch","threadId":"54839","inReplyTo":"xmqq5z4nqey1.fsf@gitster.c.googlers.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-27T18:47:27Z","receivedAt":"2020-12-27T18:49:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> But if you are arguing that when you write \"Signed-off-by:\" your\n> >> sign-off can mean something other than what DCO says it means,\n> >\n> > The DCO has clause (d), which clearly states the developer must agree\n> > that a record of his/her contribution is maintained indefinitely (and\n> > that includes his/her sign off).\n> \n> Yes. Are you saying that you are OK with (a)-(c) but not (d)?\n\nI'm saying if the author of the patch states \"I don't agree with a\nrecord of my contribution being maintained indefinitely with my sign\noff\", then clause (d) isn't met.\n\n-- \nFelipe Contreras\n"},{"id":"413050","messageId":"xmqqmtxyjjt2.fsf@gitster.c.googlers.com","threadId":"54839","inReplyTo":"5fe8d6bf1a1a3_f1c220893@natae.notmuch","subject":"Re: Nobody is THE one making contribution","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-12-28T10:39:53Z","receivedAt":"2020-12-28T10:40:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> \n>> >> But if you are arguing that when you write \"Signed-off-by:\" your\n>> >> sign-off can mean something other than what DCO says it means,\n>> >\n>> > The DCO has clause (d), which clearly states the developer must agree\n>> > that a record of his/her contribution is maintained indefinitely (and\n>> > that includes his/her sign off).\n>> \n>> Yes. Are you saying that you are OK with (a)-(c) but not (d)?\n>\n> I'm saying if the author of the patch states \"I don't agree with a\n> record of my contribution being maintained indefinitely with my sign\n> off\", then clause (d) isn't met.\n\nYeah, but then why does such an author add Signed-off-by: trailer to\nbegin with? Here is what Documentation/SubmittingPatches tells the\nauthors:\n\n === Certify your work by adding your `Signed-off-by` trailer\n\n To improve tracking of who did what, we ask you to certify that you\n wrote the patch or have the right to pass it on under the same license\n as ours, by \"signing off\" your patch. Without sign-off, we cannot\n accept your patches.\n\n If you can certify the below D-C-O:\n\n [[dco]]\n .Developer's Certificate of Origin 1.1\n ____\n By making a contribution to this project, I certify that:\n\n a. ...; or\n b. ...; or\n c. The contribution was provided directly to me by some other\n person who certified (a), (b) or (c) and I have not modified\n it.\n\n d. I understand and agree that this project and the contribution\n are public and that a record of the contribution (including all\n personal information I submit with it, including my sign-off) is\n maintained indefinitely and may be redistributed consistent with\n this project or the open source license(s) involved.\n ____\n\n you add a \"Signed-off-by\" trailer to your commit, that looks like\n this:\n\nSo, \"by making a contribution\", the author who added a Signed-off-by\ntrailer is certifying that (a|b|c)&d is true.\n\nPerhaps we can tighten the language to say \"If (and only if) you can\ncertify\" and that may reduce confusion?\n"},{"id":"413070","messageId":"5fe9eb45aa314_209d2088e@natae.notmuch","threadId":"54839","inReplyTo":"xmqqmtxyjjt2.fsf@gitster.c.googlers.com","subject":"Re: Nobody is THE one making contribution","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-12-28T14:27:17Z","receivedAt":"2020-12-28T14:28:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >> \n> >> >> But if you are arguing that when you write \"Signed-off-by:\" your\n> >> >> sign-off can mean something other than what DCO says it means,\n> >> >\n> >> > The DCO has clause (d), which clearly states the developer must agree\n> >> > that a record of his/her contribution is maintained indefinitely (and\n> >> > that includes his/her sign off).\n> >> \n> >> Yes. Are you saying that you are OK with (a)-(c) but not (d)?\n> >\n> > I'm saying if the author of the patch states \"I don't agree with a\n> > record of my contribution being maintained indefinitely with my sign\n> > off\", then clause (d) isn't met.\n> \n> Yeah, but then why does such an author add Signed-off-by: trailer to\n> begin with?\n\nWhy an author does anything is not something even the greatest\npsychologist of all time would know with 100% certainty, unless he/she\nreads minds, which nobody can do.\n\nAll we know is what the author does.\n\n> So, \"by making a contribution\", the author who added a Signed-off-by\n> trailer is certifying that (a|b|c)&d is true.\n\nYes, (d) is a requirement.\n\nBut agreeing (d) applies for patch A is not agreeing that it applies for\npatch B.\n\nApples are not oranges.\n\n> Perhaps we can tighten the language to say \"If (and only if) you can\n> certify\" and that may reduce confusion?\n\nClause (d) still must apply.\n\n-- \nFelipe Contreras\n"}]}