Re: [PATCH] git-blame: Make the output human readable

From: Junio C Hamano <junkio@cox.net>
Date: Mar 5, 2006, 21:28 UTC
Message-ID: <7vveuseg2u.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

> I find the first format easier to read since everything is aligned (we
> always output 15 characters for the committer's name padded with
> spaces if necessary and the line numbers are padded appropriately). It
> also takes up less space on screen since it doesn't use tabs.

Careful. The convention for names is to encode them in UTF-8, so if you mean 15 "characters" that might be OK but if it can truncate in the middle of a multibyte sequence of UTF-8 encoded single character it is a no-no.

We are talking about "casual" aligning, so I would not bring up "proportional fonts", but even on a monospace terminal and line-printer output, there still is the issue of byte count not matching columns. In an i18nized environment, aligning columns by counting bytes is a lost battle.

In any case, please make sure you do not chop a character in the middle at least [*1*].

> We may want to add an output format suitable for scripts too, which
> just lists the SHA1. But I don't think it is much more difficult to
> parse the format above, at least not if you just want the SHA1s.

Fair enough.

> It uses log(3) to compute the number of digits needed to represent the
> last line number. It is probably better to this some other way
> though...

Yup.

[Footnote]

*1* I was kind of impressed that Linus was careful about this issue when I saw the commit log chopping is only done at line boundaries. A very careful coder would have chopped the last line in the middle at character boundary, but if you do not want to bother that much, chopping at line boundary is better than chopping the last line in the middle of a character ;-).