Re: Weird mangling of a commit log entry in gitweb summary - Mailing list pgsql-www

From Julien Rouhaud
Subject Re: Weird mangling of a commit log entry in gitweb summary
Date
Msg-id 20220718155656.w2oudtnduxykvdra@jrouhaud
Whole thread Raw
In response to Re: Weird mangling of a commit log entry in gitweb summary  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: Weird mangling of a commit log entry in gitweb summary  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-www
On Mon, Jul 18, 2022 at 10:01:37AM -0400, Jonathan S. Katz wrote:
> On 7/18/22 4:37 AM, Julien Rouhaud wrote:
> > On Mon, Jul 18, 2022 at 10:27:47AM +0200, Magnus Hagander wrote:
> > >
> > > AFAICT this is not functionality that can be turned off, it's all
> > > hardcoded both in what it searches and when it does it. :/
> > >
> > > I doubt it's worth forking and maintaining a fork just to handle this
> > > situation given how seldom it shows up.
> >
> > +1, especially since it was introduced 17 years ago and this is probably the
> > first time someone notice it in our instance.
>
> Maybe it's worth reporting upstream? It seems like it's doing something very
> opinionated that may not make sense to projects using git.

Trying to guess what that code was originally supposed to do (as I can't find
anything apart from the "v203" original commit message), I'd say that it was
originally thought to shorten addresses in commit messages like

Merge master.kernel.org:/...
Merge rsync://rsync.kernel.org/...

(or other domains) but as written it will easily lead to nonsensical shortened
title.

Naively, something as simple as adding a leading whitespace in the regex would
remove 90% of wrong matches in our repo, and making sure it's not followed by
another whitespace would remove all of them AFAICS.

I will try to see if upstream would welcome such a change.



pgsql-www by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: Weird mangling of a commit log entry in gitweb summary
Next
From: Michel Schopgens
Date:
Subject: Wiki editor request