{"thread":{"id":"58216","subject":"[RFC PATCH] gitweb: improve title shortening heuristics","startedAt":"2022-07-24T06:27:12Z","lastAt":"2022-07-28T01:30:23Z","messageCount":7,"participants":["Julien Rouhaud","Junio C Hamano","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"459846","messageId":"20220724061231.jddhqns7bqx5c2xm@jrouhaud","threadId":"58216","inReplyTo":null,"subject":"[RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Julien Rouhaud","fromEmail":"rjuju123@gmail.com","sentAt":"2022-07-24T06:12:31Z","receivedAt":"2022-07-24T06:27:12Z","isPatch":true,"sender":{"key":"rjuju123@gmail.com","avatar":null},"body":"Hi,\n\nFirst of all, this is my first time on this ML so apologies in advance if I\nmissed anything in the patch submission guidelines.\n\nWe got some report recently that the commit short title on the postgres gitweb\ninstance was sometimes being mangled (1).  After a bit of digging, it appears\nto be due to some long time heuristics to remove some uninteresting parts of a\ncommit message (see 198066916a8 from August 2005).  In our case, it removed any\noccurrence of \"master.\" in the commit message even if the message contains\n\"postmaster.c\" rather than a cname (or something that looks like it), leading\nto the commit message:\n\nRemove postmaster.c's reset_shared() wrapper function.\n\nbeing displayed as:\n\nRemove postc's reset_shared() wrapper function.\n\nIt's probably some corner case for which there's barely any complaint, so it\ndoesn't look worthwhile to spend too much effort on it.  It also seems\nimpossible to make the current approach entirely bullet proof, but if we simply\nmake sure that the prefix is preceded by at least one whitespace and isn't\nfollowed by another one we could avoid almost all of the incorrect matches (and\nall of them as far as postgres is concerned).  Would that be an acceptable\ncompromise?  If yes, I'm attaching a patch that does that (and also adds git://\nand https:// to the list of trimmed protocols while at it).\n\nOtherwise, would it be acceptable to disable the whole block (the \"remove\nleading stuff of merges to make the interesting part visible\") with some new\nconfiguration option?\n\nCheers,\nJulien.\n\n[1] https://www.postgresql.org/message-id/flat/4025723.1658013974%40sss.pgh.pa.us\n\n\nFrom ed46dcd2796b9af6ba3f73d46a3141a88964ed11 Mon Sep 17 00:00:00 2001\nFrom: Julien Rouhaud <julien.rouhaud@free.fr>\nDate: Sun, 24 Jul 2022 13:17:19 +0800\nSubject: [PATCH v1] gitweb: improve title_short shortening heuristics\n\nIn order to shorten the title, some common domain prefixes can be detected and\nremoved.  However, the current regex matches those prefix anywhere in the\ntitle which makes it likely to remove it where it's not intended.\n\nTo make that case less likely, make sure that the prefix is preceded by at\nleast one whitespace and isn't followed by another whitespace.\n\nWhile at it, also add  git:// and https:// to the list of detected and trimmed\nprotocols.\n\nSigned-off-by: Julien Rouhaud <julien.rouhaud@free.fr>\n---\n gitweb/gitweb.perl | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 1835487ab2..18dd0b93fb 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3565,10 +3565,10 @@ sub parse_commit_text {\n \t\t\t\t$title =~ s/^Automatic //;\n \t\t\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n \t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(http|rsync):\\/\\///;\n+\t\t\t\t\t$title =~ s/(git|http|https|rsync):\\/\\///;\n \t\t\t\t}\n \t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(master|www|rsync)\\.//;\n+\t\t\t\t\t$title =~ s/\\s+(master|www|rsync)\\.([^\\s])/ \\2/;\n \t\t\t\t}\n \t\t\t\tif (length($title) > 50) {\n \t\t\t\t\t$title =~ s/kernel.org:?//;\n-- \n2.37.0\n\n"},{"id":"459854","messageId":"xmqqfsiq6ksb.fsf@gitster.g","threadId":"58216","inReplyTo":"20220724061231.jddhqns7bqx5c2xm@jrouhaud","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-25T01:30:44Z","receivedAt":"2022-07-25T01:30:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julien Rouhaud <rjuju123@gmail.com> writes:\n\n> Otherwise, would it be acceptable to disable the whole block (the \"remove\n> leading stuff of merges to make the interesting part visible\") with some new\n> configuration option?\n\nI personally find that \"shortening\" logic way too specific to the\nkernel project hosted at kernel.org and would be inappropriate to\nuse it anywhere else.\n\n\tif (length($title) > 50) {\n\t\t$title =~ s/^Automatic //;\n\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n\t\tif (length($title) > 50) {\n\t\t\t$title =~ s/(http|rsync):\\/\\///;\n\t\t}\n\t\tif (length($title) > 50) {\n\t\t\t$title =~ s/(master|www|rsync)\\.//;\n\t\t}\n\t\tif (length($title) > 50) {\n\t\t\t$title =~ s/kernel.org:?//;\n\t\t}\n\t\tif (length($title) > 50) {\n\t\t\t$title =~ s/\\/pub\\/scm//;\n\t\t}\n\t}\n\t$co{'title_short'} = chop_str($title, 50, 5);\n\nOf course, http:// and rsync:// are way outdated (https://, ssh://\nand git:// are probably reasonable).  Equally outdated is to merge\nbranches from master.kernel.org, www.kernel.org, or rsync.kernel.org\n(many merges are recorded as pulling from git://git.kernel.org/ or\nhttps://git.kernel.org/ these days).\n\nThe above code is all from 198066916a8 (Kay Sievers 2005-08-07), so\nit is very much understandable that its shortening heuristics no\nlonger match reality.\n\nEven worse, I somehow thought that kernel.org no longer uses gitweb\nbut uses something else.  So I suspect that nobody sheds tears if we\nremove the whole block unconditionally.  In fact, it would make the\nworld a better place.\n\n"},{"id":"459855","messageId":"20220725020534.x33hso22ab2dwyo7@jrouhaud","threadId":"58216","inReplyTo":"xmqqfsiq6ksb.fsf@gitster.g","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Julien Rouhaud","fromEmail":"rjuju123@gmail.com","sentAt":"2022-07-25T02:12:43Z","receivedAt":"2022-07-25T02:12:53Z","isPatch":true,"sender":{"key":"rjuju123@gmail.com","avatar":null},"body":"On Sun, Jul 24, 2022 at 06:30:44PM -0700, Junio C Hamano wrote:\n> Julien Rouhaud <rjuju123@gmail.com> writes:\n>\n> > Otherwise, would it be acceptable to disable the whole block (the \"remove\n> > leading stuff of merges to make the interesting part visible\") with some new\n> > configuration option?\n>\n> I personally find that \"shortening\" logic way too specific to the\n> kernel project hosted at kernel.org and would be inappropriate to\n> use it anywhere else.\n>\n> \tif (length($title) > 50) {\n> \t\t$title =~ s/^Automatic //;\n> \t\t$title =~ s/^merge (of|with) /Merge ... /i;\n> \t\tif (length($title) > 50) {\n> \t\t\t$title =~ s/(http|rsync):\\/\\///;\n> \t\t}\n> \t\tif (length($title) > 50) {\n> \t\t\t$title =~ s/(master|www|rsync)\\.//;\n> \t\t}\n> \t\tif (length($title) > 50) {\n> \t\t\t$title =~ s/kernel.org:?//;\n> \t\t}\n> \t\tif (length($title) > 50) {\n> \t\t\t$title =~ s/\\/pub\\/scm//;\n> \t\t}\n> \t}\n> \t$co{'title_short'} = chop_str($title, 50, 5);\n\nThat's probably true, although some parts (like the protocol) seemed general\nenough to me to be worth considering for general use case, and some of the\nreally specific parts seems so specific that they shouldn't really matter if\nused outside kernel.org.\n>\n> Of course, http:// and rsync:// are way outdated (https://, ssh://\n> and git:// are probably reasonable).  Equally outdated is to merge\n> branches from master.kernel.org, www.kernel.org, or rsync.kernel.org\n> (many merges are recorded as pulling from git://git.kernel.org/ or\n> https://git.kernel.org/ these days).\n>\n> Even worse, I somehow thought that kernel.org no longer uses gitweb\n> but uses something else.  So I suspect that nobody sheds tears if we\n> remove the whole block unconditionally.  In fact, it would make the\n> world a better place.\n\nWell, I'm obviously totally fine with getting rid of it.  FWIW, even the\nprotocol part wouldn't change anything for the instance hosted by postgres.\n\nI'm attaching an updated v2 patch that removes all that logic and just keeps\nthe title_short chopped at 50 chars.\n\n\nFrom ea4f31c0a2276f042322a11e258e55223863cd35 Mon Sep 17 00:00:00 2001\nFrom: Julien Rouhaud <julien.rouhaud@free.fr>\nDate: Sun, 24 Jul 2022 13:17:19 +0800\nSubject: [PATCH v2] gitweb: Remove title_short shortening heuristics\n\nThose heuristics are way outdated and too general to be useful outside of\nkernel.org.  Since kernel.org doesn't use gitweb anymore and at least one\nproject complained about incorrect behavior, entirely remove them.\n\nSigned-off-by: Julien Rouhaud <julien.rouhaud@free.fr>\n---\n gitweb/gitweb.perl | 17 -----------------\n 1 file changed, 17 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 1835487ab2..e66eb3d9ba 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3560,23 +3560,6 @@ sub parse_commit_text {\n \t\t$title =~ s/^    //;\n \t\tif ($title ne \"\") {\n \t\t\t$co{'title'} = chop_str($title, 80, 5);\n-\t\t\t# remove leading stuff of merges to make the interesting part visible\n-\t\t\tif (length($title) > 50) {\n-\t\t\t\t$title =~ s/^Automatic //;\n-\t\t\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(http|rsync):\\/\\///;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(master|www|rsync)\\.//;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/kernel.org:?//;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/\\/pub\\/scm//;\n-\t\t\t\t}\n-\t\t\t}\n \t\t\t$co{'title_short'} = chop_str($title, 50, 5);\n \t\t\tlast;\n \t\t}\n-- \n2.37.0\n\n"},{"id":"459856","messageId":"220725.86czdtrayy.gmgdl@evledraar.gmail.com","threadId":"58216","inReplyTo":"20220725020534.x33hso22ab2dwyo7@jrouhaud","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-25T05:54:34Z","receivedAt":"2022-07-25T05:57:17Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jul 25 2022, Julien Rouhaud wrote:\n\n> On Sun, Jul 24, 2022 at 06:30:44PM -0700, Junio C Hamano wrote:\n>> Julien Rouhaud <rjuju123@gmail.com> writes:\n>>\n>> > Otherwise, would it be acceptable to disable the whole block (the \"remove\n>> > leading stuff of merges to make the interesting part visible\") with some new\n>> > configuration option?\n>>\n>> I personally find that \"shortening\" logic way too specific to the\n>> kernel project hosted at kernel.org and would be inappropriate to\n>> use it anywhere else.\n>>\n>> \tif (length($title) > 50) {\n>> \t\t$title =~ s/^Automatic //;\n>> \t\t$title =~ s/^merge (of|with) /Merge ... /i;\n>> \t\tif (length($title) > 50) {\n>> \t\t\t$title =~ s/(http|rsync):\\/\\///;\n>> \t\t}\n>> \t\tif (length($title) > 50) {\n>> \t\t\t$title =~ s/(master|www|rsync)\\.//;\n>> \t\t}\n>> \t\tif (length($title) > 50) {\n>> \t\t\t$title =~ s/kernel.org:?//;\n>> \t\t}\n>> \t\tif (length($title) > 50) {\n>> \t\t\t$title =~ s/\\/pub\\/scm//;\n>> \t\t}\n>> \t}\n>> \t$co{'title_short'} = chop_str($title, 50, 5);\n>\n> That's probably true, although some parts (like the protocol) seemed general\n> enough to me to be worth considering for general use case, and some of the\n> really specific parts seems so specific that they shouldn't really matter if\n> used outside kernel.org.\n>>\n>> Of course, http:// and rsync:// are way outdated (https://, ssh://\n>> and git:// are probably reasonable).  Equally outdated is to merge\n>> branches from master.kernel.org, www.kernel.org, or rsync.kernel.org\n>> (many merges are recorded as pulling from git://git.kernel.org/ or\n>> https://git.kernel.org/ these days).\n>>\n>> Even worse, I somehow thought that kernel.org no longer uses gitweb\n>> but uses something else.  So I suspect that nobody sheds tears if we\n>> remove the whole block unconditionally.  In fact, it would make the\n>> world a better place.\n>\n> Well, I'm obviously totally fine with getting rid of it.  FWIW, even the\n> protocol part wouldn't change anything for the instance hosted by postgres.\n>\n> I'm attaching an updated v2 patch that removes all that logic and just keeps\n> the title_short chopped at 50 chars.\n\nPlease \"inline\" your patches, see \"Sending your patches\" in\nDocumentation/SubmittingPatches (I.e. send it with git-send-email, or\nsimilar). I see this as:\n\n> [2. text/plain; v2-0001-gitweb-Remove-title_short-shortening-heuristics.patch]...\n\nIn my MUA. But manually extracting it and quoting it:\n\n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 1835487ab2..e66eb3d9ba 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -3560,23 +3560,6 @@ sub parse_commit_text {\n>  \t\t$title =~ s/^    //;\n>  \t\tif ($title ne \"\") {\n>  \t\t\t$co{'title'} = chop_str($title, 80, 5);\n> -\t\t\t# remove leading stuff of merges to make the interesting part visible\n> -\t\t\tif (length($title) > 50) {\n> -\t\t\t\t$title =~ s/^Automatic //;\n> -\t\t\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/(http|rsync):\\/\\///;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/(master|www|rsync)\\.//;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/kernel.org:?//;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/\\/pub\\/scm//;\n> -\t\t\t\t}\n> -\t\t\t}\n>  \t\t\t$co{'title_short'} = chop_str($title, 50, 5);\n>  \t\t\tlast;\n\nThis looks good to me, The one thing I'd add is that we're just running:\n\n\t git rev-list --parents --header  --max-count=1 HEAD\n\nAnd parsing that, but if we're truncating things perhaps we should just\nrun \"git log\" or \"git show\" with the \"%<(<N>[,trunc|ltrunc|mtrunc])\"\nsyntax or similar.\n\nThat's obviously a follow-up, but if anyone's interested in deleting\neven more code here...\n"},{"id":"459972","messageId":"20220726135911.ycvgwbkixb3ei6w3@jrouhaud","threadId":"58216","inReplyTo":"220725.86czdtrayy.gmgdl@evledraar.gmail.com","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Julien Rouhaud","fromEmail":"rjuju123@gmail.com","sentAt":"2022-07-26T13:59:11Z","receivedAt":"2022-07-26T13:59:19Z","isPatch":true,"sender":{"key":"rjuju123@gmail.com","avatar":null},"body":"Hi,\n\nOn Mon, Jul 25, 2022 at 07:54:34AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n> Please \"inline\" your patches, see \"Sending your patches\" in\n> Documentation/SubmittingPatches (I.e. send it with git-send-email, or\n> similar). I see this as:\n>\n> > [2. text/plain; v2-0001-gitweb-Remove-title_short-shortening-heuristics.patch]...\n\nAh I'm sorry about that.  For the archives sake (and to make sure that I\ncorrectly configured my MUA), I'm reattaching the v2 inline.\n\n> This looks good to me, The one thing I'd add is that we're just running:\n>\n> \t git rev-list --parents --header  --max-count=1 HEAD\n>\n> And parsing that, but if we're truncating things perhaps we should just\n> run \"git log\" or \"git show\" with the \"%<(<N>[,trunc|ltrunc|mtrunc])\"\n> syntax or similar.\n>\n> That's obviously a follow-up, but if anyone's interested in deleting\n> even more code here...\n\nNote that I didn't try to do anything about that.  I have the feeling that\ngitweb isn't wildly used nowadays, especially for bigger projects, so it didn't\nseems worth spending too much efforts.\n\nFrom ea4f31c0a2276f042322a11e258e55223863cd35 Mon Sep 17 00:00:00 2001\nFrom: Julien Rouhaud <julien.rouhaud@free.fr>\nDate: Sun, 24 Jul 2022 13:17:19 +0800\nSubject: [PATCH v2] gitweb: Remove title_short shortening heuristics\n\nThose heuristics are way outdated and too general to be useful outside of\nkernel.org.  Since kernel.org doesn't use gitweb anymore and at least one\nproject complained about incorrect behavior, entirely remove them.\n\nSigned-off-by: Julien Rouhaud <julien.rouhaud@free.fr>\n---\n\nNotes:\n    Patch re-submitted inline rather than in attachment, sorry about the\n    previous attachments.\n\n gitweb/gitweb.perl | 17 -----------------\n 1 file changed, 17 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 1835487ab2..e66eb3d9ba 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3560,23 +3560,6 @@ sub parse_commit_text {\n \t\t$title =~ s/^    //;\n \t\tif ($title ne \"\") {\n \t\t\t$co{'title'} = chop_str($title, 80, 5);\n-\t\t\t# remove leading stuff of merges to make the interesting part visible\n-\t\t\tif (length($title) > 50) {\n-\t\t\t\t$title =~ s/^Automatic //;\n-\t\t\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(http|rsync):\\/\\///;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/(master|www|rsync)\\.//;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/kernel.org:?//;\n-\t\t\t\t}\n-\t\t\t\tif (length($title) > 50) {\n-\t\t\t\t\t$title =~ s/\\/pub\\/scm//;\n-\t\t\t\t}\n-\t\t\t}\n \t\t\t$co{'title_short'} = chop_str($title, 50, 5);\n \t\t\tlast;\n \t\t}\n--\n2.37.0\n"},{"id":"460007","messageId":"xmqq4jz3vzgb.fsf@gitster.g","threadId":"58216","inReplyTo":"20220726135911.ycvgwbkixb3ei6w3@jrouhaud","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-27T06:31:32Z","receivedAt":"2022-07-27T06:31:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julien Rouhaud <rjuju123@gmail.com> writes:\n\n> Hi,\n>\n> On Mon, Jul 25, 2022 at 07:54:34AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> Please \"inline\" your patches, see \"Sending your patches\" in\n>> Documentation/SubmittingPatches (I.e. send it with git-send-email, or\n>> similar). I see this as:\n>>\n>> > [2. text/plain; v2-0001-gitweb-Remove-title_short-shortening-heuristics.patch]...\n>\n> Ah I'm sorry about that.  For the archives sake (and to make sure that I\n> correctly configured my MUA), I'm reattaching the v2 inline.\n\nThanks.  It is not for the archives' sake; I do not take (or notice\nin the first place) patches in attachments, simply because rarely\nanybody reviews attachments.\n\n>> This looks good to me, The one thing I'd add is that we're just running:\n>>\n>> \t git rev-list --parents --header  --max-count=1 HEAD\n>>\n>> And parsing that, but if we're truncating things perhaps we should just\n>> run \"git log\" or \"git show\" with the \"%<(<N>[,trunc|ltrunc|mtrunc])\"\n>> syntax or similar.\n>>\n>> That's obviously a follow-up, but if anyone's interested in deleting\n>> even more code here...\n>\n> Note that I didn't try to do anything about that.  I have the feeling that\n> gitweb isn't wildly used nowadays, especially for bigger projects, so it didn't\n> seems worth spending too much efforts.\n>\n> From ea4f31c0a2276f042322a11e258e55223863cd35 Mon Sep 17 00:00:00 2001\n\nWhen you are sending the patch in for real, after making a non-patch\ndiscussion (all of the above), you can write a \"scissors\" line\n\n----- >8 -----\n\nright here, immediately before your \"From:\" and \"Subject:\".  What it\ndoes is to tell \"git am\" on the receiving end to ignore everything\nit saw up to that point and pretend the message starts there.\n\nYou do not want to include \"From <object name>\" line that is used as\nan internal separator in the mailbox format.  You do not want to\ninclude the \"Date:\" in-body header, either.  \"From:\" and \"Subject:\"\nare used often because they are frequently different from the e-mail\n(e.g. in the message I am responding to, the sender is rjuju123@gmail,\nnot julien.rouhaud@free.fr, and we want the latter on the From: line\nbecause that is what appears on the Signed-off-by: line).\n\n> From: Julien Rouhaud <julien.rouhaud@free.fr>\n> Subject: [PATCH v2] gitweb: Remove title_short shortening heuristics\n>\n> Those heuristics are way outdated and too general to be useful outside of\n> kernel.org.  Since kernel.org doesn't use gitweb anymore and at least one\n> project complained about incorrect behavior, entirely remove them.\n>\n> Signed-off-by: Julien Rouhaud <julien.rouhaud@free.fr>\n> ---\n>\n> Notes:\n>     Patch re-submitted inline rather than in attachment, sorry about the\n>     previous attachments.\n\nThanks.  Will queue.\n\n\n>  gitweb/gitweb.perl | 17 -----------------\n>  1 file changed, 17 deletions(-)\n>\n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 1835487ab2..e66eb3d9ba 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -3560,23 +3560,6 @@ sub parse_commit_text {\n>  \t\t$title =~ s/^    //;\n>  \t\tif ($title ne \"\") {\n>  \t\t\t$co{'title'} = chop_str($title, 80, 5);\n> -\t\t\t# remove leading stuff of merges to make the interesting part visible\n> -\t\t\tif (length($title) > 50) {\n> -\t\t\t\t$title =~ s/^Automatic //;\n> -\t\t\t\t$title =~ s/^merge (of|with) /Merge ... /i;\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/(http|rsync):\\/\\///;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/(master|www|rsync)\\.//;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/kernel.org:?//;\n> -\t\t\t\t}\n> -\t\t\t\tif (length($title) > 50) {\n> -\t\t\t\t\t$title =~ s/\\/pub\\/scm//;\n> -\t\t\t\t}\n> -\t\t\t}\n>  \t\t\t$co{'title_short'} = chop_str($title, 50, 5);\n>  \t\t\tlast;\n>  \t\t}\n> --\n> 2.37.0\n"},{"id":"460063","messageId":"20220728013009.pqiobsquf7u6yyb4@jrouhaud","threadId":"58216","inReplyTo":"xmqq4jz3vzgb.fsf@gitster.g","subject":"Re: [RFC PATCH] gitweb: improve title shortening heuristics","fromName":"Julien Rouhaud","fromEmail":"rjuju123@gmail.com","sentAt":"2022-07-28T01:30:09Z","receivedAt":"2022-07-28T01:30:23Z","isPatch":true,"sender":{"key":"rjuju123@gmail.com","avatar":null},"body":"Hi,\n\nOn Tue, Jul 26, 2022 at 11:31:32PM -0700, Junio C Hamano wrote:\n>\n> When you are sending the patch in for real, after making a non-patch\n> discussion (all of the above), you can write a \"scissors\" line\n>\n> ----- >8 -----\n>\n> right here, immediately before your \"From:\" and \"Subject:\".  What it\n> does is to tell \"git am\" on the receiving end to ignore everything\n> it saw up to that point and pretend the message starts there.\n>\n> You do not want to include \"From <object name>\" line that is used as\n> an internal separator in the mailbox format.  You do not want to\n> include the \"Date:\" in-body header, either.  \"From:\" and \"Subject:\"\n> are used often because they are frequently different from the e-mail\n> (e.g. in the message I am responding to, the sender is rjuju123@gmail,\n> not julien.rouhaud@free.fr, and we want the latter on the From: line\n> because that is what appears on the Signed-off-by: line).\n\nOk, got it.\n\n> > From: Julien Rouhaud <julien.rouhaud@free.fr>\n> > Subject: [PATCH v2] gitweb: Remove title_short shortening heuristics\n> >\n> > Those heuristics are way outdated and too general to be useful outside of\n> > kernel.org.  Since kernel.org doesn't use gitweb anymore and at least one\n> > project complained about incorrect behavior, entirely remove them.\n> >\n> > Signed-off-by: Julien Rouhaud <julien.rouhaud@free.fr>\n> > ---\n> >\n> > Notes:\n> >     Patch re-submitted inline rather than in attachment, sorry about the\n> >     previous attachments.\n>\n> Thanks.  Will queue.\n\nThanks!\n"}]}