Jeff King, 17.01.2009: > 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. I think, it doesn't. > 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 But it doesn't automatically color the SHA1. > (yes, --abbrev-commit > works, too, but I find the '...' a pointless waste of space). And they are annoying for selecting with the mouse doubleclick, at least Konsole selects the SHA1 including the '...'. Xterm doesn't and I haven't looked if Konsole can be configured to do so, but without the '...' it would probably work regardless of the terminal emulator and its setting. Markus -- 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
