{"thread":{"id":"58157","subject":"[PATCH] tests: fix incorrect --write-junit-xml code","startedAt":"2022-07-14T09:00:43Z","lastAt":"2022-08-12T21:00:57Z","messageCount":9,"participants":["Johannes Schindelin via GitGitGadget","Junio C Hamano","Ævar Arnfjörð Bjarmason","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"459034","messageId":"pull.1288.git.1657789234416.gitgitgadget@gmail.com","threadId":"58157","inReplyTo":null,"subject":"[PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-07-14T09:00:34Z","receivedAt":"2022-07-14T09:00:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nIn 78d5e4cfb4b (tests: refactor --write-junit-xml code, 2022-05-21),\nthis developer refactored the `--write-junit-xml` code a bit, including\nthe part where the current test case's title was used in a `set`\ninvocation, but failed to account for the fact that some test cases'\ntitles start with a long option, which the `set` misinterprets as being\nintended for parsing.\n\nLet's fix this by using the `set -- <...>` form.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n    tests(JUnit): fix a regression introduced by refactoring\n    \n    As if another data point was needed to corroborate my claim that\n    refactorings are neither free of cost nor of risk, this patch fixes a\n    regression I myself introduced while refactoring the JUnit XML output\n    code. At least this refactoring was motivated by an ulterior goal to\n    improve Git's contributor experience, not just refactoring for\n    refactoring's sake.\n    \n    Unfortunately, I noticed this regression no earlier than when I needed\n    to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed\n    release, I could not use GitHub Actions for the CI testing, so I had to\n    reinstate Git's Azure Pipeline.\n    \n    It will probably surprise only few, if at all, that this is far from the\n    only regression in the CI code that I had to fix just so I could run the\n    Azure Pipeline successfully. I plan on contributing all of these\n    regression fixes, of course, packaged into neat little,\n    logically-separate patch series that should be easy on reviewers.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1288%2Fdscho%2Ffix-junit-xml-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1288/dscho/fix-junit-xml-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1288\n\n t/test-lib-junit.sh | 10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nindex c959183c7e2..79c31c788b9 100644\n--- a/t/test-lib-junit.sh\n+++ b/t/test-lib-junit.sh\n@@ -46,7 +46,7 @@ finalize_test_case_output () {\n \tshift\n \tcase \"$test_case_result\" in\n \tok)\n-\t\tset \"$*\"\n+\t\tset -- \"$*\"\n \t\t;;\n \tfailure)\n \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n@@ -65,17 +65,17 @@ finalize_test_case_output () {\n \t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n \t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n \t\tfi\n-\t\tset \"$1\" \"      $junit_insert\"\n+\t\tset -- \"$1\" \"      $junit_insert\"\n \t\t;;\n \tfixed)\n-\t\tset \"$* (breakage fixed)\"\n+\t\tset -- \"$* (breakage fixed)\"\n \t\t;;\n \tbroken)\n-\t\tset \"$* (known breakage)\"\n+\t\tset -- \"$* (known breakage)\"\n \t\t;;\n \tskip)\n \t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n-\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n+\t\tset -- \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n \t\t;;\n \tesac\n \n\nbase-commit: 4e2a4d1dd44367d7783f33b169698f2930ff13c0\n-- \ngitgitgadget\n"},{"id":"459048","messageId":"xmqq35f38yeb.fsf@gitster.g","threadId":"58157","inReplyTo":"pull.1288.git.1657789234416.gitgitgadget@gmail.com","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-14T16:14:20Z","receivedAt":"2022-07-14T16:14:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\nwrites:\n\n>     Unfortunately, I noticed this regression no earlier than when I needed\n>     to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed\n>     release, I could not use GitHub Actions for the CI testing, so I had to\n>     reinstate Git's Azure Pipeline.\n\nI wonder if it would make your life easier if the same GitHub\nActions CI stuff were available for the Cabal repository we use for\nembargoed work, by allowing you to use the same validation for usual\nreleases and the enbargoed ones?\n\n\"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\nwrites:\n\n>  t/test-lib-junit.sh | 10 +++++-----\n>  1 file changed, 5 insertions(+), 5 deletions(-)\n>\n> diff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\n> index c959183c7e2..79c31c788b9 100644\n> --- a/t/test-lib-junit.sh\n> +++ b/t/test-lib-junit.sh\n> @@ -46,7 +46,7 @@ finalize_test_case_output () {\n>  \tshift\n>  \tcase \"$test_case_result\" in\n>  \tok)\n> -\t\tset \"$*\"\n> +\t\tset -- \"$*\"\n>  \t\t;;\n>  \tfailure)\n>  \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n> @@ -65,17 +65,17 @@ finalize_test_case_output () {\n>  \t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n>  \t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n>  \t\tfi\n> -\t\tset \"$1\" \"      $junit_insert\"\n> +\t\tset -- \"$1\" \"      $junit_insert\"\n>  \t\t;;\n>  \tfixed)\n> -\t\tset \"$* (breakage fixed)\"\n> +\t\tset -- \"$* (breakage fixed)\"\n>  \t\t;;\n>  \tbroken)\n> -\t\tset \"$* (known breakage)\"\n> +\t\tset -- \"$* (known breakage)\"\n>  \t\t;;\n>  \tskip)\n>  \t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n> -\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n> +\t\tset -- \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n>  \t\t;;\n>  \tesac\n\nOK.  Ancient shells did not understand \"--\" and it was idiomatic to\nsay \"set x ...; shift\", but we already do assume \"set --\" is usable\neverywhere we care about in many of our scripts and tests.\n\nLooks good to me.\n\nThanks.  Will queue.\n"},{"id":"459131","messageId":"220715.865yjy1zxa.gmgdl@evledraar.gmail.com","threadId":"58157","inReplyTo":"xmqq35f38yeb.fsf@gitster.g","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-15T09:25:23Z","receivedAt":"2022-07-15T09:35:36Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jul 14 2022, Junio C Hamano wrote:\n\n> \"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\n> writes:\n>\n>>     Unfortunately, I noticed this regression no earlier than when I needed\n>>     to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed\n>>     release, I could not use GitHub Actions for the CI testing, so I had to\n>>     reinstate Git's Azure Pipeline.\n>\n> I wonder if it would make your life easier if the same GitHub\n> Actions CI stuff were available for the Cabal repository we use for\n> embargoed work, by allowing you to use the same validation for usual\n> releases and the enbargoed ones?\n\nIsn't it. Looking at\ne.g. https://github.com/git/cabal/actions/runs/2284056293 (private link)\nthat's the CI run for the latest push to \"master\" (same as\nhttps://github.com/git/git/commit/e8005e4871f130c4e402ddca2032c111252f070a).\n\nSo I didn't get this idea that we must have Azure to resurrect for\n\"private CI\", don't we have that already, and anyone can use it by\nre-pushing git.git to a private repo (the limitation being that on\nGitHub you can't make a private fork of a public repo)?\n\n"},{"id":"459136","messageId":"220715.86wncezmm3.gmgdl@evledraar.gmail.com","threadId":"58157","inReplyTo":"pull.1288.git.1657789234416.gitgitgadget@gmail.com","subject":"never refactor v.s. testing (was: [PATCH] tests: fix incorrect --write-junit-xml code)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-15T09:35:41Z","receivedAt":"2022-07-15T10:39:07Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jul 14 2022, Johannes Schindelin via GitGitGadget wrote:\n\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> [...]\n>     As if another data point was needed to corroborate my claim that\n>     refactorings are neither free of cost nor of risk, this patch fixes a\n>     regression I myself introduced while refactoring the JUnit XML output\n>     code. At least this refactoring was motivated by an ulterior goal to\n>     improve Git's contributor experience, not just refactoring for\n>     refactoring's sake.\n>     \n>     Unfortunately, I noticed this regression no earlier than when I needed\n>     to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed\n>     release, I could not use GitHub Actions for the CI testing, so I had to\n>     reinstate Git's Azure Pipeline.\n>     \n>     It will probably surprise only few, if at all, that this is far from the\n>     only regression in the CI code that I had to fix just so I could run the\n>     Azure Pipeline successfully. I plan on contributing all of these\n>     regression fixes, of course, packaged into neat little,\n>     logically-separate patch series that should be easy on reviewers.\n\nI take your point that any code change carries risk, but I really think\nwalking away with the lesson that \"refactorings\" are bad is the wrong\nthing to draw from this.\n\nThis is a textbook example of the value of testing. Code can break\nbecause it's refactored directly, or because a library or tool it\ndepended on changed, etc.\n\nThe problem here isn't that we changed some code, but that it was\nchanged blindly.\n\nHindsight is 20/20 on the specifics of any bug, and I don't mean to pick\non you for having made a change without adding tests here in\nparticular. I've also done it, and will probably do it in the future\nwhere I'm overly sure of myself.\n\nBut the idea that we should first consider basic lack of test coverage\nbefore making (further) changes really isn't 20/20 hindsight. I think it\nshould be a basic part of our workflow, particularly in cases like this\n(and the bisect case I pointed out in another thread[1]) where we can\nsee that we could remove the entire feature (or sub-feature for [1]) and\nstill pass 100% of our test.\n\nAs test coverage approaches 100% (which is often impossible in practice)\nthe risk of refactorings approaches (but never reaches) 0%. Plot them on\na mental graph and they're roughly inversely proportional to one\nanother. We'll almost never reach 100% and 0% in practice.\n\nIn this case we have no test coverage for --write-junit-xml before or\nafter this change. Before it were dying right away with just running\ntest-lib.sh with --write-junit-xml, So even the below up to\n\"test_must_be_empty\" would catch it.\n\nSo we don't need the hypothetical 100%, just getting to 0.1% is enough,\nand the below hopefully gets us past that to 1% (a lot of\n--write-junit-xml remains completely untested):\n\n1. https://lore.kernel.org/git/220714.86fsj4356l.gmgdl@evledraar.gmail.com/\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 17a268ccd1b..f3c12314787 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -238,6 +238,34 @@ test_expect_success 'subtest: --verbose option' '\n \tEOF\n '\n \n+test_expect_success 'subtest: --write-junit-xml option' '\n+\t# both --write-junit-xml and lib-subtest.sh expect to use \"out\"\n+\tGIT_TEST_JUNIT_DIRECTORY=.junit-xml &&\n+\texport GIT_TEST_JUNIT_DIRECTORY &&\n+\n+\twrite_and_run_sub_test_lib_test_err write-junit-xml \\\n+\t\t--write-junit-xml <<-\\EOF &&\n+\ttest_expect_success \"--true <>\" \"true\"\n+\ttest_expect_success \"--false <>\" \"false\"\n+\ttest_done\n+\tEOF\n+\ttest_must_be_empty write-junit-xml/err &&\n+\n+\tsed -e \"s/^> //\" -e \"s/time[^>]*/.../g\" >expect <<-\\EOF &&\n+\t> <testsuites>\n+\t>   <testsuite name=\"write-junit-xml\" ...>\n+\t>     <testcase name=\"write.1 --true &lt;&gt;\" classname=\"write\" ...>\n+\t>     </testcase>\n+\t>     <testcase name=\"write.2 --false &lt;&gt;\" classname=\"write\" ...>\n+\t>       <failure message=\"not ok 2 - --false &lt;&gt;\"> false&#x0a;</failure>\n+\t>     </testcase>\n+\t>   </testsuite>\n+\t> </testsuites>\n+\tEOF\n+\tsed -e \"s/time[^>]*/.../g\" <write-junit-xml/.junit-xml/TEST-write-junit-xml.xml >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_expect_success 'subtest: --verbose-only option' '\n \trun_sub_test_lib_test_err \\\n \t\tt1234-verbose \\\ndiff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\nindex 79c31c788b9..2aac1c6c548 100644\n--- a/t/test-lib-junit.sh\n+++ b/t/test-lib-junit.sh\n@@ -22,7 +22,7 @@\n # that are are called at the appropriate times during the test runs.\n \n start_test_output () {\n-\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/out\"\n+\tjunit_xml_dir=\"$TEST_OUTPUT_DIRECTORY/${GIT_TEST_JUNIT_DIRECTORY:-out}\"\n \tmkdir -p \"$junit_xml_dir\"\n \tjunit_xml_base=${1##*/}\n \tjunit_xml_path=\"$junit_xml_dir/TEST-${junit_xml_base%.sh}.xml\"\n"},{"id":"460825","messageId":"s4s2qr56-2948-p025-rrq7-qq56p9oo844r@tzk.qr","threadId":"58157","inReplyTo":"xmqq35f38yeb.fsf@gitster.g","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-08T13:40:09Z","receivedAt":"2022-08-08T13:40:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 14 Jul 2022, Junio C Hamano wrote:\n\n> \"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\n> writes:\n>\n> >     Unfortunately, I noticed this regression no earlier than when I needed\n> >     to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed\n> >     release, I could not use GitHub Actions for the CI testing, so I had to\n> >     reinstate Git's Azure Pipeline.\n>\n> I wonder if it would make your life easier\n\nIt would make my life easier if Chesterton's Fences were left alone ;-)\n\n> if the same GitHub Actions CI stuff were available for the Cabal\n> repository we use for embargoed work, by allowing you to use the same\n> validation for usual releases and the enbargoed ones?\n\nGitHub Actions are available in the Cabal repository. The problem is that\ndue to the private nature of said repository, the number of included build\nminutes is limited.\n\nI did manage to get GitHub to sponsor the Git project specifically to\nincrease said build minutes. But that only scratches the problem at the\nsurface.\n\nI still think that we need to slow the heck down with refactoring for\nrefactoring's sake because it's not only the CI builds that are affected.\nI pay a lot of time to accommodate for those refactorings, and so do\nothers, and the benefit of most of those refactorings escapes me. My best\nguess is that they adapt Git's source code to individual tastes, which is\nof course a losing game because too many individuals with too many\ndifferent tastes are involved in the Git project. Unless we start valuing\nparticular individuals' tastes over others', which I believe we should not\ndo.\n\nYou asked me in private to provide more reviews for those refactorings so\nthat they see some push-back, but I lack the bandwidth for that.\n\n> \"Johannes Schindelin via GitGitGadget\" <gitgitgadget@gmail.com>\n> writes:\n>\n> >  t/test-lib-junit.sh | 10 +++++-----\n> >  1 file changed, 5 insertions(+), 5 deletions(-)\n> >\n> > diff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh\n> > index c959183c7e2..79c31c788b9 100644\n> > --- a/t/test-lib-junit.sh\n> > +++ b/t/test-lib-junit.sh\n> > @@ -46,7 +46,7 @@ finalize_test_case_output () {\n> >  \tshift\n> >  \tcase \"$test_case_result\" in\n> >  \tok)\n> > -\t\tset \"$*\"\n> > +\t\tset -- \"$*\"\n> >  \t\t;;\n> >  \tfailure)\n> >  \t\tjunit_insert=\"<failure message=\\\"not ok $test_count -\"\n> > @@ -65,17 +65,17 @@ finalize_test_case_output () {\n> >  \t\t\tjunit_insert=\"$junit_insert<system-err>$(xml_attr_encode \\\n> >  \t\t\t\t\"$(cat \"$GIT_TEST_TEE_OUTPUT_FILE\")\")</system-err>\"\n> >  \t\tfi\n> > -\t\tset \"$1\" \"      $junit_insert\"\n> > +\t\tset -- \"$1\" \"      $junit_insert\"\n> >  \t\t;;\n> >  \tfixed)\n> > -\t\tset \"$* (breakage fixed)\"\n> > +\t\tset -- \"$* (breakage fixed)\"\n> >  \t\t;;\n> >  \tbroken)\n> > -\t\tset \"$* (known breakage)\"\n> > +\t\tset -- \"$* (known breakage)\"\n> >  \t\t;;\n> >  \tskip)\n> >  \t\tmessage=\"$(xml_attr_encode --no-lf \"$skipped_reason\")\"\n> > -\t\tset \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n> > +\t\tset -- \"$1\" \"      <skipped message=\\\"$message\\\" />\"\n> >  \t\t;;\n> >  \tesac\n>\n> OK.  Ancient shells did not understand \"--\" and it was idiomatic to\n> say \"set x ...; shift\", but we already do assume \"set --\" is usable\n> everywhere we care about in many of our scripts and tests.\n>\n> Looks good to me.\n>\n> Thanks.  Will queue.\n\nThank you,\nDscho\n"},{"id":"460834","messageId":"xmqqv8r2smvr.fsf@gitster.g","threadId":"58157","inReplyTo":"s4s2qr56-2948-p025-rrq7-qq56p9oo844r@tzk.qr","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-08T16:47:36Z","receivedAt":"2022-08-08T16:48:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I still think that we need to slow the heck down with refactoring for\n> refactoring's sake because it's not only the CI builds that are affected.\n> I pay a lot of time to accommodate for those refactorings, and so do\n> others, and the benefit of most of those refactorings escapes me.\n\nAbsolutely.\n\n> You asked me in private to provide more reviews for those refactorings so\n> that they see some push-back, but I lack the bandwidth for that.\n\nI do remember telling you to push back what you do not want to see\nin 'seen' and advance to 'next'.  If everybody lacks the bandwidth\nfor shooting down bad ideas and only has time to promote their own\nideas, which are not guaranteed to be good ones, it does not lead\nto a good place X-<.\n\n"},{"id":"460879","messageId":"3qn5r283-3232-4s58-8q9s-n67o407nr816@tzk.qr","threadId":"58157","inReplyTo":"xmqqv8r2smvr.fsf@gitster.g","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-09T08:42:35Z","receivedAt":"2022-08-09T08:42:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 8 Aug 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > You asked me in private to provide more reviews for those refactorings so\n> > that they see some push-back, but I lack the bandwidth for that.\n>\n> I do remember telling you to push back what you do not want to see\n> in 'seen' and advance to 'next'.  If everybody lacks the bandwidth\n> for shooting down bad ideas and only has time to promote their own\n> ideas, which are not guaranteed to be good ones, it does not lead\n> to a good place X-<.\n\nThe funny thing is that you're usually simply not picking up patches that\ndo not get any reviews, but for these refactorings it is somehow\ndifferent, and I do not understand why it needs to be different.\n\nI do not _want_ to spend time reviewing patch series of dubious benefit.\nAnd that would hold true even if I could justify spending that time, which\nI can't.\n\nThere are so many more contributions that promise a much higher return of\ninvestment for reviewing them.\n\nCiao,\nDscho\n"},{"id":"461016","messageId":"xmqqpmh8kkfb.fsf@gitster.g","threadId":"58157","inReplyTo":"3qn5r283-3232-4s58-8q9s-n67o407nr816@tzk.qr","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-10T18:44:40Z","receivedAt":"2022-08-10T18:44:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> The funny thing is that you're usually simply not picking up patches that\n> do not get any reviews, but for these refactorings it is somehow\n> different, and I do not understand why it needs to be different.\n\nWell, I am not sure if encouraging the maintainer to drop patches\nthat are not reviewed is a good overall direction you would want to\ngo in.\n\nBut let's try that.  Less work for me, less disruption to our tree,\nand the world may be quieter and more pleasant ;-)\n"},{"id":"461152","messageId":"78npn9qp-2263-sosp-8901-4484s4499q99@tzk.qr","threadId":"58157","inReplyTo":"xmqqpmh8kkfb.fsf@gitster.g","subject":"Re: [PATCH] tests: fix incorrect --write-junit-xml code","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-12T21:00:55Z","receivedAt":"2022-08-12T21:00:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 10 Aug 2022, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n> > The funny thing is that you're usually simply not picking up patches that\n> > do not get any reviews, but for these refactorings it is somehow\n> > different, and I do not understand why it needs to be different.\n>\n> Well, I am not sure if encouraging the maintainer to drop patches\n> that are not reviewed is a good overall direction you would want to\n> go in.\n\nI am not encouraging you to drop high-quality patches that have a clear\nbenefit to the project and/or Git's users. You probably know me better\nthan to assume that I would ever do such a thing. You probably meant this\ncomment tongue-in-cheek, but I cannot really tell.\n\nIt's about these long patch series that touch everything and their dog and\nthe end result brings no clear benefit to users nor the Git project\nitself. I can easily imagine how wonderful it would be not to see such\npatch series ever again. ;-)\n\n> But let's try that.  Less work for me, less disruption to our tree,\n> and the world may be quieter and more pleasant ;-)\n\nAmen!\n\nCiao,\nDscho\n"}]}