Re: Weird mangling of a commit log entry in gitweb summary
От | Julien Rouhaud |
---|---|
Тема | Re: Weird mangling of a commit log entry in gitweb summary |
Дата | |
Msg-id | 20220718155656.w2oudtnduxykvdra@jrouhaud обсуждение исходный текст |
Ответ на | Re: Weird mangling of a commit log entry in gitweb summary ("Jonathan S. Katz" <jkatz@postgresql.org>) |
Ответы |
Re: Weird mangling of a commit log entry in gitweb summary
|
Список | 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 по дате отправления: