summaryrefslogtreecommitdiff
path: root/ws.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-01-05 23:17:40 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-01-07 19:34:54 -0800
commit91229834c293302c4456e732ddef7ace0df6e471 (patch)
tree37e522a5e5f19265320f1dcc6657e6d63cf4ed35 /ws.c
parentpreparing for 2.10.3 (diff)
downloadtgif-91229834c293302c4456e732ddef7ace0df6e471.tar.xz
blame: fix alignment with --abbrev=40
The blame command internally adds 1 to any requested sha1 abbreviation length, and then subtracts it when outputting a boundary commit. This lets regular and boundary sha1s line up visually, but it misses one corner case. When the requested length is 40, we bump the value to 41. But since we only have 40 characters, that's all we can show (fortunately the truncation is done by a printf precision field, so it never tries to read past the end of the buffer). So a normal sha1 shows 40 hex characters, and a boundary sha1 shows "^" plus 40 hex characters. The result is misaligned. The "-l" option to show long sha1s gets around this by skipping the "abbrev" variable entirely and just always using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it does mean that boundary commits only have 39 characters printed. This is somewhat odd, but it does look good visually: the results are aligned and left-justified. The alternative would be to allocate an extra column that would contain either an extra space or the "^" boundary marker. As this is by definition the human-readable view, it's probably not that big a deal either way (and of course --porcelain, etc, correctly produce correct 40-hex sha1s). But for consistency, this patch teaches --abbrev=40 to produce the same output as "-l" (always left-aligned, with 40-hex for normal sha1s, and "^" plus 39-hex for boundaries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'ws.c')
0 files changed, 0 insertions, 0 deletions