Going one step further from git blame --reverse ?

Simon Richter· Nov 6, 2025, 02:30 UTC · lore

Hi,

Once again I've found myself in the annoying position to find out why a particular line that was present in an older version was removed (i.e. I needed to find the first commit it is not present in).

git blame --reverse brings me close, but not quite there, and quite often it will point at a commit where several branches diverged.

Is there a way to make it go one step further and report the commit whose message is most likely to explain things?

    Simon

Ben Knoble· Nov 6, 2025, 03:18 UTC · re: Simon Richter · lore

Re: Going one step further from git blame --reverse ?

Show 11 quoted lines

> Le 5 nov. 2025 à 21:30, Simon Richter <Simon.Richter@hogyros.de> a écrit :
> 
> Hi,
> 
> Once again I've found myself in the annoying position to find out why a particular line that was present in an older version was removed (i.e. I needed to find the first commit it is not present in).
> 
> git blame --reverse brings me close, but not quite there, and quite often it will point at a commit where several branches diverged.
> 
> Is there a way to make it go one step further and report the commit whose message is most likely to explain things?
> 
>   Simon

This is a situation in which I usually reach for the pickaxe. Say you know commit deadbeef had the line 'hello world' in file co.de; then the following should find where it disappeared, assuming the line is unique enough:

    git log -S 'hello world' deadbeef.. co.de

Omit the commit range if not sure. For deleted lines, the pickaxe should first fine the deletion of interest. It helps to feed as much of the line as possible, but partial contents are still useful (and I often use function or variable names to see uses over time).