Re: Mail thread references in commits
| От | Magnus Hagander |
|---|---|
| Тема | Re: Mail thread references in commits |
| Дата | |
| Msg-id | CABUevEyHp=xnb_y6Wkko9uYiwDAHdcsfjqtrCYDcq-0nVDz_4Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Mail thread references in commits (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Mail thread references in commits
|
| Список | pgsql-hackers |
On Sat, Nov 19, 2016 at 5:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@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_j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@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 views.
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.
В списке pgsql-hackers по дате отправления: