Re: Mail thread references in commits

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Joshua Drake <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Mail thread references in commits
Date: 2016-11-28 14:49:01
Message-ID: 20161128144901.vy6othbaorgv644z@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander wrote:

> I don't really read perl enough to take it apart. But
> http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code
> (we're probably on an older version). I'm guessing it's coming out of
> format_log_line (
> http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n2035). (the
> version we have only has the part that looks for the hash).

I think if we do want to fork, we should be looking at git_print_log
http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n4580
There's a regexp match that looks for "https://" but only when preceded
with "link: " (which is a bit odd, isn't it?).

> I wonder if it's worth forking gitweb to make it do explicitly what we want
> for this -- that is recognize all the different kinds of things that would
> be interesting here. But that fork should probably be done by somebody with
> some more perl skills than me :)

I think changing message-id links to URLs would be veyr handy, but
before proposing a fork I would like to have a better idea of how much
effort it entails.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-11-28 14:50:34 Re: UNDO and in-place update
Previous Message Ashutosh Bapat 2016-11-28 14:42:21 Re: Declarative partitioning - another take