Re: Commit subject line - Mailing list pgsql-hackers

On 05/06/2013 10:19 AM, Magnus Hagander wrote:
> On Fri, May 3, 2013 at 9:07 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On 2013-05-03 14:54:23 -0400, Andrew Dunstan wrote:
>>> On 05/03/2013 02:43 PM, Tom Lane wrote:
>>>> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>>>>> On 03.05.2013 20:56, Bruce Momjian wrote:
>>>>>> On Fri, May  3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
>>>>>>> Yeah. The recommended style is to have the first line be 50 chars or
>>>>>>> less, which is a bit unfortunate - it can be a challenge to keep to
>>>>>>> that limit for a meaningful or comprehensive subject.
>>>>> Oh, that's tight. I didn't know about the 50 char recommendation. I've
>>>>> tried to keep mine < 76 chars, so that when you do "git log", it fits on
>>>>> a 80 char display with the 4 char indentation that git log does.
>>>> Yeah, that's news to me too.  I've been using a 75-char line length for
>>>> all my commit messages since we switched to git.  It's frequently tough
>>>> enough to get a useful headline into 75 chars --- I can't see trying to
>>>> do 50.
>>> man git-commit says:
>>>
>>>     Though not required, it’s a good idea to begin the commit message
>>>     with a single short (less than 50 character) line summarizing the
>>>     change, followed by a blank line and then a more thorough
>>>     description. Tools that turn commits into email, for example, use
>>>     the first line on the Subject: line and the rest of the commit in
>>>     the body.
>>>
>>> I'd be happy to use 75 or whatever if we could convince the email tools not
>>> to truncate the subject lines at 50.
>> Its worth to notice that neither git nor the kernel adhere to that
>> limit...
> FWIW, the tool we use to generate the commit emails truncate it at 80
> (minus the "pgsql: " header). We can increase that, but it only fixes
> the email one, and not the one that people look at on the web...

In practice, something else must be further truncating it, at about 64
chars by the look of it - see for example
<http://www.postgresql.org/message-id/E1UVTFj-00079k-2r@gemulon.postgresql.org>

Re your other point, github at least seems to elide at about 70 chars  -
see
<https://github.com/postgres/postgres/commit/b42ea7981ce1e7484951a22662937541066d8647>
- where Joe used a very long first sentence rather than a show summary
line. I don't know if gitweb could be induced to elide after a greater
length - I bet it could fairly easily. There does seem to be lots of
spare screen real estate on the commit summary and history pages, which
I think is where this occurs.

cheers

andrew