On Sat, Nov 19, 2016 at 5:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Andrew Dunstan <and...@dunslane.net> writes:
> > On 11/19/2016 10:11 AM, Stephen Frost wrote:
> >> That's actually not the case if we use a hash, because the client could
> >> figure out what the hash is before sending it.
> > The fact that it could possibly be done is not a good reason for doing
> > it.
> Quite.  I will *not* go along with any proposal that requires me to
> duplicate some hashing logic being done elsewhere.  Way too much risk
> of error there.

SHA-1 is fairly well defined, but sure, I can see your issue -- dealing
with leading spaces/trailing spaces and whatnot can certainly cause trouble.

> > Every proposal along these lines strikes me as making more unobvious
> > hoops for people to jump through. We're just reinventing the wheel here
> > because we don't like the color of the standard wheels that some email
> > MUAs produce.
> Yeah, anything like this would be going very very far out of our way to
> keep these lines in commit messages under an arbitrary limit (which we're
> already exceeding anyway in many cases).  I'm inclined to think we should
> just straight up decide that having the message link be a clickable URL is
> worth the longer lines, or that it is not.  Personally I vote for "not",
> but I recognize that I might be in the minority.
> BTW, before we give up completely on reconciling the two objectives,
> is anyone aware of a line-continuation convention that would be likely
> to work?  If we could do something like
> Discussion: https://www.postgresql.org/message-id/\
> caf4au4w6rrh_j1bvvhzposrihcog7sgj3lsx0ty8zdwhht8...@mail.gmail.com

I don't think there is such a thing. There is continuation at the mail
header line level, but not for an URL in the contents of the message. And
this is in the commit message itself, so nobody really knows what the
viewer will be using -- it could be our list archives or a local copy of
the commit mail, but it could also be the git log (viewed locally, through
our gitweb site, or through github or some other such site).

We can put just the message-id in there and hack our gitweb instance to
know how to turn that into links on our site. But that would only cover
*our* gitweb, and not all the other potential ways to view it. I'm pretty
sure there is no standard that will work across all the different potential

We can replace the website part with a http://postgr.es/m/<messageid> which
will make it a bit shorter and still as easy to generate from the client
side and to search off. It'd be trivial to do, and since there is no state
held at the forwarder for it, it wouldn't introduce a risk of "losing the
forwards at some point in the future". But the bulk of the URL, being the
messageid, would remain.

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to