{"thread":{"id":"58501","subject":"[PATCH] cmd-list.perl: fix identifying man sections","startedAt":"2022-09-23T07:03:52Z","lastAt":"2022-09-26T17:41:01Z","messageCount":10,"participants":["Martin Ågren","Ævar Arnfjörð Bjarmason","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"463499","messageId":"20220923070334.1970213-1-martin.agren@gmail.com","threadId":"58501","inReplyTo":null,"subject":"[PATCH] cmd-list.perl: fix identifying man sections","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-09-23T07:03:34Z","receivedAt":"2022-09-23T07:03:52Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"We attribute each documentation text file to a man section by finding a\nline in the file that looks like \"gitfoo()\". Commit cc75e556a9\n(\"scalar: add to 'git help -a' command list\", 2022-09-02) updated this\nlogic to look not only for \"gitfoo\" but also \"scalarfoo\". In doing so,\nit forgot to account for the fact that after the updated regex has found\na match, the man section is no longer to be found in `$1` but now lives\nin `$2`.\n\nThis makes our git(1) manpage look as follows:\n\n Main porcelain commands\n git-add(git)\n Add file contents to the index.\n\n [...]\n\n gitk(git)\n The Git repository browser.\n\n scalar(scalar)\n A tool for managing large Git repositories.\n\nRestore the man sections by grabbing the correct value out of the regex\nmatch.\n\nSigned-off-by: Martin Ågren \n---\n This is a v2.38.0-rc1 regression.\n\n Documentation/cmd-list.perl | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\nindex 9515a499a3..16451d81b8 100755\n--- a/Documentation/cmd-list.perl\n+++ b/Documentation/cmd-list.perl\n@@ -11,7 +11,7 @@ sub format_one {\n \topen I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n \twhile () {\n \t\tif (/^(git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n-\t\t\t$mansection = $1;\n+\t\t\t$mansection = $2;\n \t\t\tnext;\n \t\t}\n \t\tif (/^NAME$/) {\n-- \n2.38.0.rc1.355.g7147cddc23\n\n"},{"id":"463501","messageId":"220923.86wn9u4joo.gmgdl@evledraar.gmail.com","threadId":"58501","inReplyTo":"20220923070334.1970213-1-martin.agren@gmail.com","subject":"Re: [PATCH] cmd-list.perl: fix identifying man sections","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-23T07:38:12Z","receivedAt":"2022-09-23T07:47:02Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 23 2022, Martin Ågren wrote:\n\n> We attribute each documentation text file to a man section by finding a\n> line in the file that looks like \"gitfoo()\". Commit cc75e556a9\n> (\"scalar: add to 'git help -a' command list\", 2022-09-02) updated this\n> logic to look not only for \"gitfoo\" but also \"scalarfoo\". In doing so,\n> it forgot to account for the fact that after the updated regex has found\n> a match, the man section is no longer to be found in `$1` but now lives\n> in `$2`.\n>\n> This makes our git(1) manpage look as follows:\n>\n> Main porcelain commands\n> git-add(git)\n> Add file contents to the index.\n>\n> [...]\n>\n> gitk(git)\n> The Git repository browser.\n>\n> scalar(scalar)\n> A tool for managing large Git repositories.\n>\n> Restore the man sections by grabbing the correct value out of the regex\n> match.\n>\n> Signed-off-by: Martin Ågren \n> ---\n> This is a v2.38.0-rc1 regression.\n>\n> Documentation/cmd-list.perl | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\n> index 9515a499a3..16451d81b8 100755\n> --- a/Documentation/cmd-list.perl\n> +++ b/Documentation/cmd-list.perl\n> @@ -11,7 +11,7 @@ sub format_one {\n> \topen I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n> \twhile () {\n> \t\tif (/^(git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n> -\t\t\t$mansection = $1;\n> +\t\t\t$mansection = $2;\n> \t\t\tnext;\n> \t\t}\n> \t\tif (/^NAME$/) {\n\nOuch, good catch!\n\nIn the v1 review for scalar[1] I pointed out that I had a local patch\nwhere this is instead:\n\n\tif (/^[a-z0-9-]*\\(([0-9])\\)$/) {\n\t\t$mansection = $1;\n\nThe v2 at [2] which I didn't get around to reviewing (sorry!) then\nintroduced this logic error.\n\nVictoria: Did you find some reason to not just take the version I had?\nThe doc-diff with Martin's above is empty, i.e. it's the same in\npractice, but if we don't need to hard-code our top-level commands for\nno reason I don't see why we'd maintain this list of them here.\n\nOn the proposed rc patch: FWIW we can also just use (?:) groupings\ninstead of a capture:\n\n\tif (/^(?:git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n\nIt has the same effect, but arguably makes more sense. I.e. if we don't\ncare about $1 let's not capture the thing we don't care about into $1 in\nthe first place.\n\n1. https://lore.kernel.org/git/220831.86y1v48h2x.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/070f195f027e5601b88ca6a0d4c9991b472ad9ab.1662134210.git.gitgitgadget@gmail.com/\n"},{"id":"463503","messageId":"20220923080733.1995862-1-martin.agren@gmail.com","threadId":"58501","inReplyTo":"220923.86wn9u4joo.gmgdl@evledraar.gmail.com","subject":"[PATCH v2] cmd-list.perl: fix identifying man sections","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-09-23T08:07:33Z","receivedAt":"2022-09-23T08:08:06Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"We attribute each documentation text file to a man section by finding a\nline in the file that looks like \"gitfoo()\". Commit cc75e556a9\n(\"scalar: add to 'git help -a' command list\", 2022-09-02) updated this\nlogic to look not only for \"gitfoo\" but also \"scalarfoo\". In doing so,\nit forgot to account for the fact that after the updated regex has found\na match, the man section is no longer to be found in `$1` but now lives\nin `$2`.\n\nThis makes our git(1) manpage look as follows:\n\n Main porcelain commands\n git-add(git)\n Add file contents to the index.\n\n [...]\n\n gitk(git)\n The Git repository browser.\n\n scalar(scalar)\n A tool for managing large Git repositories.\n\nRestore the man sections by not capturing the (git|scalar) part of the\nmatch into `$1`.\n\nAs noted by Ævar [1], we could even match any \"foo\" rather than just\n\"gitfoo\" and \"scalarfoo\", but that's a larger change. For now, just fix\nthe regression in cc75e556a9.\n\n[1] https://lore.kernel.org/git/220923.86wn9u4joo.gmgdl@evledraar.gmail.com/#t\n\nHelped-by: Ævar Arnfjörð Bjarmason \nSigned-off-by: Martin Ågren \n---\n Thanks Ævar for having a look at v1.\n\n Documentation/cmd-list.perl | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\nindex 9515a499a3..755a110bc4 100755\n--- a/Documentation/cmd-list.perl\n+++ b/Documentation/cmd-list.perl\n@@ -10,7 +10,7 @@ sub format_one {\n \t$state = 0;\n \topen I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n \twhile () {\n-\t\tif (/^(git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n+\t\tif (/^(?:git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n \t\t\t$mansection = $1;\n \t\t\tnext;\n \t\t}\n-- \n2.38.0.rc1.355.g7147cddc23\n\n"},{"id":"463506","messageId":"220923.86fsgi4gl6.gmgdl@evledraar.gmail.com","threadId":"58501","inReplyTo":"20220923080733.1995862-1-martin.agren@gmail.com","subject":"Re: [PATCH v2] cmd-list.perl: fix identifying man sections","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-23T08:37:33Z","receivedAt":"2022-09-23T08:53:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 23 2022, Martin Ågren wrote:\n\n> We attribute each documentation text file to a man section by finding a\n> line in the file that looks like \"gitfoo()\". Commit cc75e556a9\n> (\"scalar: add to 'git help -a' command list\", 2022-09-02) updated this\n> logic to look not only for \"gitfoo\" but also \"scalarfoo\". In doing so,\n> it forgot to account for the fact that after the updated regex has found\n> a match, the man section is no longer to be found in `$1` but now lives\n> in `$2`.\n>\n> This makes our git(1) manpage look as follows:\n>\n> Main porcelain commands\n> git-add(git)\n> Add file contents to the index.\n>\n> [...]\n>\n> gitk(git)\n> The Git repository browser.\n>\n> scalar(scalar)\n> A tool for managing large Git repositories.\n>\n> Restore the man sections by not capturing the (git|scalar) part of the\n> match into `$1`.\n>\n> As noted by Ævar [1], we could even match any \"foo\" rather than just\n> \"gitfoo\" and \"scalarfoo\", but that's a larger change. For now, just fix\n> the regression in cc75e556a9.\n\nThanks for the quick turn-around, this looks good to me in this form.\n\n> [1] https://lore.kernel.org/git/220923.86wn9u4joo.gmgdl@evledraar.gmail.com/#t\n>\n> Helped-by: Ævar Arnfjörð Bjarmason \n> Signed-off-by: Martin Ågren \n> ---\n> Thanks Ævar for having a look at v1.\n>\n> Documentation/cmd-list.perl | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\n> index 9515a499a3..755a110bc4 100755\n> --- a/Documentation/cmd-list.perl\n> +++ b/Documentation/cmd-list.perl\n> @@ -10,7 +10,7 @@ sub format_one {\n> \t$state = 0;\n> \topen I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n> \twhile () {\n> -\t\tif (/^(git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n> +\t\tif (/^(?:git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n> \t\t\t$mansection = $1;\n> \t\t\tnext;\n> \t\t}\n\nJust for anyone doing future archaeology / digging into the \"larger\nchange\": The reason I felt safe in removing the \"git\" matching entirely\nis because the larger context here is that we're parsing only the very\nstart of the *.txt. I.e. we would not want this:\n\t\n\tgit(1)\n\t======\n\t\n\tNAME\n\t----\n\tgit - the stupid content tracker\n\t\n\n foo(2)\n\nTo report Documentation/git.txt as being a \"foo\" in man section 2, but\nthat will not happen because as soon as we see a \"NAME\" line followed by\na \"----\" line we'll extract that one line of description, so even if our\nregex would have eagerly matched that \"foo(2)\" we won't see it.\n\nNow, having written and looked at this with fresh eyes this would be an\neven better & more logical thing to do:\n\t\n\tdiff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\n\tindex 755a110bc48..0bc4c803a10 100755\n\t--- a/Documentation/cmd-list.perl\n\t+++ b/Documentation/cmd-list.perl\n\t@@ -1,38 +1,38 @@\n\t #!/usr/bin/perl -w\n\t \n\t use File::Compare qw(compare);\n\t \n\t sub format_one {\n\t \tmy ($out, $nameattr) = @_;\n\t \tmy ($name, $attr) = @$nameattr;\n\t \tmy ($state, $description);\n\t \tmy $mansection;\n\t \t$state = 0;\n\t \topen I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n\t \twhile () {\n\t-\t\tif (/^(?:git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n\t+\t\tif (/^\\Q$name\\E\\(([0-9])\\)$/) {\n\t \t\t\t$mansection = $1;\n\t \t\t\tnext;\n\t \t\t}\n\t \t\tif (/^NAME$/) {\n\t \t\t\t$state = 1;\n\t \t\t\tnext;\n\t \t\t}\n\t \t\tif ($state == 1 && /^----$/) {\n\t \t\t\t$state = 2;\n\t \t\t\tnext;\n\t \t\t}\n\t \t\tnext if ($state != 2);\n\t \t\tchomp;\n\t \t\t$description = $_;\n\t \t\tlast;\n\t \t}\n\t \tclose I;\n\t \tif (!defined $description) {\n\t \t\tdie \"No description found in $name.txt\";\n\t \t}\n\t \tif (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {\n\t \t\tprint $out \"linkgit:$name\\[$mansection\\]::\\n\\t\";\n\t \t\tif ($attr =~ / deprecated /) {\n\t \t\t\tprint $out \"(deprecated) \";\n\t \t\t}\n\nIt yields the exact same result as Martin's patch above according to the\ndoc-diff, but as the -U25 context shows we already have a hard\ndependency on the \"scalar -\" part of the description line matching the\nname of the file (\"scalar.txt\") is something we should be doing.\n\nAnyway, this is more than good enough for now, thanks! There's also much\nbigger issues with the script, and we can leave that all aside from now\n(e.g. if it dies the Makefile doesn't report an error, ouch!).\n"},{"id":"463508","messageId":"CAN0heSrnN4Vjcj6KDG+DZkZ7_GWz5dex2Qq0To6CGVH7_zux4Q@mail.gmail.com","threadId":"58501","inReplyTo":"220923.86fsgi4gl6.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2] cmd-list.perl: fix identifying man sections","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-09-23T11:42:37Z","receivedAt":"2022-09-23T11:43:00Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On Fri, 23 Sept 2022 at 10:53, Ævar Arnfjörð Bjarmason wrote:\n>\n> Thanks for the quick turn-around, this looks good to me in this form.\n\nThanks for reviewing.\n\n> Now, having written and looked at this with fresh eyes this would be an\n> even better & more logical thing to do:\n\n> open I, '<', \"$name.txt\" or die \"No such file $name.txt\";\n> while () {\n> - if (/^(?:git|scalar)[a-z0-9-]*\\(([0-9])\\)$/) {\n> + if (/^\\Q$name\\E\\(([0-9])\\)$/) {\n> $mansection = $1;\n> next;\n> }\n\nRight, we know what we want there, so this does look reasonable.\n\n> Anyway, this is more than good enough for now, thanks! There's also much\n> bigger issues with the script, and we can leave that all aside from now\n> (e.g. if it dies the Makefile doesn't report an error, ouch!).\n\nMartin\n"},{"id":"463522","messageId":"xmqqtu4yuirh.fsf@gitster.g","threadId":"58501","inReplyTo":"20220923080733.1995862-1-martin.agren@gmail.com","subject":"Re: [PATCH v2] cmd-list.perl: fix identifying man sections","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-09-23T17:01:54Z","receivedAt":"2022-09-23T17:02:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Ågren writes:\n\n> We attribute each documentation text file to a man section by finding a\n> line in the file that looks like \"gitfoo()\". Commit cc75e556a9\n> (\"scalar: add to 'git help -a' command list\", 2022-09-02) updated this\n> logic to look not only for \"gitfoo\" but also \"scalarfoo\". In doing so,\n> it forgot to account for the fact that after the updated regex has found\n> a match, the man section is no longer to be found in `$1` but now lives\n> in `$2`.\n>\n> This makes our git(1) manpage look as follows:\n>\n> Main porcelain commands\n> git-add(git)\n> Add file contents to the index.\n\nThanks. Will queue.\n"},{"id":"463559","messageId":"Yy4uDW9YjpleFUHW@coredump.intra.peff.net","threadId":"58501","inReplyTo":"20220923070334.1970213-1-martin.agren@gmail.com","subject":"Re: [PATCH] cmd-list.perl: fix identifying man sections","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-09-23T22:07:09Z","receivedAt":"2022-09-23T22:07:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 23, 2022 at 09:03:34AM +0200, Martin Ågren wrote:\n\n> This makes our git(1) manpage look as follows:\n> \n> Main porcelain commands\n> git-add(git)\n> Add file contents to the index.\n> \n> [...]\n> \n> gitk(git)\n> The Git repository browser.\n> \n> scalar(scalar)\n> A tool for managing large Git repositories.\n\nGood catch. The patch looks good (I was going to suggest ?:, but I see\nÆvar beat me to it).\n\nI wondered if we might have caught this in a more automatic way. The\noutput of:\n\n cd Documentation\n ./doc-diff cc75e556a9^ cc75e556a9\n\nmakes the problem apparent, but I don't fault reviewers for not running\nit. I rarely remember to do so. And in general you need a human looking\nat doc-diff output to know if it was the intended change or not.\n\nI wondered if it might be worth running\n\n ./doc-diff v2.37.0 v2.38.0-rc1\n\nnear a release to scan over all of the changes. But the diff is over\n8000 lines, and I admit my eyes glazed over before I got to the\nproblematic hunks (even though I knew I was looking for them!). You can\nlimit it a bit with --diff-filter=a, which drops new entries (which\ncan't have regressed!), but it's still over 4000 lines.\n\nSo I dunno. I think doc-diff is a potentially useful tool, but I'm not\nsure how to point the human attention at the right spot to find a bug.\nMaybe \"given enough eyeballs, all bugs are shallow\" is our best bet\nhere. After all, it did find this bug before the release. :)\n\n-Peff\n"},{"id":"463605","messageId":"CAN0heSpPGuSYb1nEyA3RuV+ACrXjHu+YqxAsfZN62EHVqcQ9Mg@mail.gmail.com","threadId":"58501","inReplyTo":"Yy4uDW9YjpleFUHW@coredump.intra.peff.net","subject":"Re: [PATCH] cmd-list.perl: fix identifying man sections","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-09-26T07:16:25Z","receivedAt":"2022-09-26T07:16:42Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On Sat, 24 Sept 2022 at 00:07, Jeff King wrote:\n>\n> I wondered if we might have caught this in a more automatic way. The\n> output of:\n>\n> cd Documentation\n> ./doc-diff cc75e556a9^ cc75e556a9\n>\n> makes the problem apparent, but I don't fault reviewers for not running\n> it. I rarely remember to do so. And in general you need a human looking\n> at doc-diff output to know if it was the intended change or not.\n>\n> I wondered if it might be worth running\n>\n> ./doc-diff v2.37.0 v2.38.0-rc1\n>\n> near a release to scan over all of the changes. But the diff is over\n> 8000 lines, and I admit my eyes glazed over before I got to the\n> problematic hunks (even though I knew I was looking for them!).\n\nI know how you felt when you looked at that doc-diff... I was lucky\nenough to first look at\n\n ./doc-diff v2.37.0 v2.38.0-rc0\n\nso that when I then looked at\n\n ./doc-diff v2.38.0-rc0 v2.38.0-rc1\n\nthis stood out quite well.\n\n> So I dunno. I think doc-diff is a potentially useful tool, but I'm not\n> sure how to point the human attention at the right spot to find a bug.\n\nI try to do some such doc-diffing every now and then, and in particular\naround rc time. It has caught a few buglets, usually nothing major.\n\nI've also done\n\n ./doc-diff origin/next origin/seen\n\nat times to catch such things a lot earlier, but it's not often that I\nfind the time to do so / think about doing it.\n\n> Maybe \"given enough eyeballs, all bugs are shallow\" is our best bet\n> here. After all, it did find this bug before the release. :)\n\nYeah, and luck never hurts -- I think it's fair to assume that I would\nhave missed this bug if it hadn't come in after rc0.\n\nMartin\n"},{"id":"463629","messageId":"220926.86czbi1cj2.gmgdl@evledraar.gmail.com","threadId":"58501","inReplyTo":"Yy4uDW9YjpleFUHW@coredump.intra.peff.net","subject":"Re: [PATCH] cmd-list.perl: fix identifying man sections","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-26T13:35:06Z","receivedAt":"2022-09-26T15:07:43Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 23 2022, Jeff King wrote:\n\n> On Fri, Sep 23, 2022 at 09:03:34AM +0200, Martin Ågren wrote:\n>\n>> This makes our git(1) manpage look as follows:\n>> \n>> Main porcelain commands\n>> git-add(git)\n>> Add file contents to the index.\n>> \n>> [...]\n>> \n>> gitk(git)\n>> The Git repository browser.\n>> \n>> scalar(scalar)\n>> A tool for managing large Git repositories.\n>\n> Good catch. The patch looks good (I was going to suggest ?:, but I see\n> Ævar beat me to it).\n>\n> I wondered if we might have caught this in a more automatic way. The\n> output of:\n>\n> cd Documentation\n> ./doc-diff cc75e556a9^ cc75e556a9\n\nFWIW I asked before on-list[1] why the CI output of\nhttps://github.com/gitster/git wasn't visible, I don't know if it's a\nsetting Junio can adjust, or something else.\n\nI wanted to set something up to scrape the WC E-Mails, and see what the\nCI status of those topics was individually.\n\nAnd, if others found it useful eventually, perhaps send that as a\nfollow-up to the list. I.e. if CI for the topic passes, what (if any)\nthe output differences are. We could then just run a \"doc-diff\" in the\nCI, and report (as part of some matrix) a checkmark next to those that\nhave doc changes.\n\nOf course I could re-push all of the topics myself, but that would take\na long time to complete, and compete with any other use I have for CI\nmyself. So piggy-backing on gitster's would be much better, if they're\neven there in the first place...\n\n1. https://lore.kernel.org/git/220114.86fspqrxbw.gmgdl@evledraar.gmail.com/\n"},{"id":"463643","messageId":"xmqqk05qqd4y.fsf@gitster.g","threadId":"58501","inReplyTo":"CAN0heSpPGuSYb1nEyA3RuV+ACrXjHu+YqxAsfZN62EHVqcQ9Mg@mail.gmail.com","subject":"Re: [PATCH] cmd-list.perl: fix identifying man sections","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-09-26T17:06:05Z","receivedAt":"2022-09-26T17:41:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Ågren writes:\n\n> I've also done\n>\n> ./doc-diff origin/next origin/seen\n>\n> at times to catch such things a lot earlier, but it's not often that I\n> find the time to do so / think about doing it.\n\nAh, that probably is a good thing to do on my end after picking\nwhich topics to merge to 'next' and before merging them, i.e.\n\n * Find ones that are marked as \"Merge to 'next'\";\n * \"git checkout --detach next\" and then merge them;\n * Do the doc-diff between 'next' and HEAD.\n\nin addition to my usual set of tests, SANITIZE=, etc.\n\nThanks for an idea.\n"}]}