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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
