git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[BUG] git-blame: --color-lines ignores --ignore-rev

From
SMSeth McDonald <sethmcmail@pm.me>
Date
Feb 1, 2026, 07:32 UTC
Message-ID
<aX8BjoOGPIytGXjD@McDaDebianPC>
G'day all,

I believe I've found a bug regarding how git-blame(1) colours its output when invoked with both --color-lines and --ignore-rev.

== Summary == git-blame(1) has two options of interest. '--color-lines' colours a line (in cyan by default) if it has the same blame as the preceding line. And '--ignore-rev <rev>' prevents any line from being blamed on <rev>, instead blaming such lines on the most recent commit prior to <rev> that modified those lines.

When used in combination, it is possible for consecutive lines to have the same blame without the latter lines being coloured correctly. I first observed this behaviour on Git 2.47.3, but have since compiled the latest release candidate (Git 2.53.0.rc2) and have observed the same behaviour.

== Reproducibility == I was able to construct a minimal working example as follows.

First create and cd(1) into a temporary directory. Let's name it 'git-test'.

$ mkdir git-test $ cd git-test

Make git(1) ignore the system and global config files. This is mainly to aid in reproducibility.

$ export GIT_CONFIG_SYSTEM=/dev/null $ export GIT_CONFIG_GLOBAL=/dev/null

Initialise a Git repository.

$ git init --initial-branch main Initialized empty Git repository in /.../git-test/.git/

Now set some default values. In particular, set blame.coloring to repeatedLines; equivalent to the --color-lines option for git-blame(1).

$ git config set user.name 'John Git' $ git config set user.email 'johngit@for.real' $ git config set blame.coloring repeatedLines $ git config set blame.date short

Create a file (let's name it 'text'), give it some text, and commit it.
$ echo Why hello there how are you | xargs -n1 > text
$ git add text
$ git commit --message 'init'
[main (root-commit) xxxxxxx] init
 1 file changed, 6 insertions(+)
 create mode 100644 text
Then fixup some punctuation in the file and commit it.
$ sed -i -e '3s/$/!/' -e '4s/h/H/' -e '6s/$/?/' text
$ git add text
$ git commit --message 'fix'
[main yyyyyyy] fix
 1 file changed, 3 insertions(+), 3 deletions(-)
If we now blame the file, we get the following.

$ git blame text ^xxxxxxx (John Git YYYY-MM-DD 1) Why ^xxxxxxx (John Git YYYY-MM-DD 2) hello yyyyyyyy (John Git YYYY-MM-DD 3) there! yyyyyyyy (John Git YYYY-MM-DD 4) How ^xxxxxxx (John Git YYYY-MM-DD 5) are yyyyyyyy (John Git YYYY-MM-DD 6) you?

Where lines 2 and 4 are coloured cyan. This is expected, since their listed commits are the same as that on lines 1 and 3, respectively.

Now consider the output of git-blame(1) if we ignore the second commit.

$ git blame --ignore-rev HEAD text ^xxxxxxx (John Git YYYY-MM-DD 1) Why ^xxxxxxx (John Git YYYY-MM-DD 2) hello ^xxxxxxx (John Git YYYY-MM-DD 3) there! ^xxxxxxx (John Git YYYY-MM-DD 4) How ^xxxxxxx (John Git YYYY-MM-DD 5) are ^xxxxxxx (John Git YYYY-MM-DD 6) you?

My expected behaviour of git-blame(1) is to colour lines 2-6 cyan. This is because lines 1-6 all blame the same commit, meaning lines 2-6 all have the same blame as their respective preceding lines. And as the man page for git-blame(1) states:

$ MANWIDTH=72 man git-blame | sed -n '/--color-lines$/,/^$/p'
       --color-lines
           Color line annotations in the default format differently if
           they come from the same commit as the preceding line. This
           makes it easier to distinguish code blocks introduced by
           different commits. The color defaults to cyan and can be
           adjusted using the color.blame.repeatedLines config option.

However, the actual behaviour of git-blame(1) is to colour only lines 2 and 4 cyan. That is, it colours the output as if the --ignore-rev option was not given.

== Environment == The following info was added verbatim from git-bugreport(1).

[System Info]
git version:
git version 2.53.0.rc2
cpu: x86_64
built from commit: ab380cb80b0727f7f2d7f6b17592ae6783e9820c
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: disabled
gettext: enabled
libcurl: 8.14.1
OpenSSL: OpenSSL 3.5.4 30 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 6.12.63+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.63-1 (2025-12-30) x86_64
compiler info: gnuc: 14.2
libc info: glibc: 2.41
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
And here's some extra info, in case it helps:
OS: Debian GNU/Linux 13 (trixie)
Terminal: GNOME Terminal 3.56.2
bash: (GNU bash) 5.2.37(1)-release (x86_64-pc-linux-gnu)
sed: (GNU sed) 4.9
xargs: (GNU findutils) 4.10.0
I'd be happy to further elaborate or provide help if needed.
-- 
Take care,
	Seth McDonald.

On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289
Next: René Scharfe
Message 1 of 6 in “[BUG] git-blame: --color-lines ignores --ignore-rev”
  1. Seth McDonaldFeb 1, 2026
  2. blame: fix coloring for repeated suspectsRené Scharfe, Feb 1, 2026
  3. Seth McDonaldFeb 2, 2026
  4. Junio C HamanoFeb 2, 2026
  5. René ScharfeFeb 2, 2026
  6. Junio C HamanoFeb 2, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.