From: Jeff King Date: Sat, 17 Jan 2009 01:40:57 GMT Subject: 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 Message-ID: <20090117014057.GA15331@coredump.intra.peff.net> In-Reply-To: <2faad3050901160706y297a98d4r35340e4811ca3d2b@mail.gmail.com> 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