Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that

[Jeff King <peff@peff.net>]

On Fri, Jan 16, 2009 at 03:06:34PM +0000, Baz wrote:

> > At the beginning I tried to fulfil this limit, but often it's not easy.
> > So should it be adjusted to a slightly higher value in the documentation
> > or even split into a recommended limit (e.g. 50) and a recommended
> > absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
> 
> The 50 character limit is for the first line, try "git log
> --pretty=oneline" and it should be obvious why.

I'm not sure it makes sense to make a workflow recommendation that the
git project itself does not follow. Of 14590 non-merge commits in
git.git, 6940 (nearly 50%) have subject lines longer than 50
characters.

In practice, is this a problem for people using git.git?

Personally, I find --pretty=oneline unreadable because so much of the
screen real estate is wasted on random characters that I don't care
about. I find --pretty=tformat:'%h %s' much nicer (yes, --abbrev-commit
works, too, but I find the '...' a pointless waste of space).

For reference, here are the percentiles of subject lines in git.git
longer than X:

 X | %
50 | 48%
60 | 24%
65 | 14%
70 |  8%

So it seems that quite a large chunk are between 50 and 65 characters.
Which still leaves room for "Subject: " or 8 characters of hash at the
beginning.

> perl -ne '$lim = (50,0,72)[($.>3?3:$.)-1];

Ugh. Would a little whitespace have killed you? ;P

> (I wish I'd had something like this when one of the devs here pushed a
> commit with a 346-line message,
> just listing what files he was changing...doh)

Well, yes. That's just insane.

-Peff