From: Matthew Hughes <matthewhughes934@gmail.com>
To: git@vger.kernel.org
Subject: Crash on git log with -L and -G on file rename
Date: Tue, 3 Mar 2026 20:42:20 +0000 [thread overview]
Message-ID: <aac-QdjY1ohAqgw_@desktop> (raw)
Hi,
I hit a crash (assertion error) running `git log` with both `-L` and `-G` under
certain conditions. I've created script to reproduce the behaviour in a fresh
git repo:
#!/usr/bin/env bash
set -o errexit
git init .
# Note: example is .rs file, but it should work with anything that -L understands
echo "fn my_func() {}" > file.rs
# 1. file named 'file.rs'
git add file.rs
git commit --message 'Add the file'
# 2. separate branch with the file renamed
git checkout -b some-branch
git mv file.rs new_file.rs
git commit --message 'Move the file'
git checkout -
git commit --allow-empty --message 'Some extra commit so we get a merge commit'
# 3. merge: one parent has file.rs, the other has new_file.rs
git merge --no-edit some-branch
# 4. post merge, move the file back
git mv new_file.rs file.rs
git commit --message 'Move the file back'
# 5. things go BOOM
git log -L:my_func:file.rs -G '.'
I'm not sure if _every_ step in that script is necessary, but it's the simplest
setup I could figure out to trigger the crash. Running that script I hit the
error:
git: line-log.c:1056: process_diff_filepair: Assertion `pair->two->oid_valid' failed.
Aborted (core dumped) git log -L:my_func:file.rs -G '.'
The backtrace shows that the failed assertion occurs under
`process_ranges_merge_commit`, so maybe there's an issue with the file being
renamed on both sides of the merge?
The crash requires both flags to trigger, remove either and it will run fine.
I've tested the above on the `git` from my system package manager on Arch
Linux: git version 2.53.0, and one built from source at
2cc71917514657b93014134350864f4849edfc83 (the version of 'master' checked out
on my machine at the time). I don't think reproduction relies on any specific
config since I've had it trigger with both `GIT_CONFIG_GLOBAL` and
`GIT_CONFIG_SYSTEM` set to `/dev/null`
Just for reference, I originally triggered the bug in the `rustfmt` repo[1]
(checked-out at cebab3e99259be82ff069e5ae89e91855d79e534) running:
git log -G offset_left -L:format_trait:src/items.rs
Link: github.com/rust-lang/rustfmt [1]
next reply other threads:[~2026-03-03 20:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 20:42 Matthew Hughes [this message]
2026-03-03 23:49 ` Crash on git log with -L and -G on file rename Kristoffer Haugsbakk
2026-03-04 2:06 ` Junio C Hamano
2026-03-04 3:01 ` Koji Nakamaru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aac-QdjY1ohAqgw_@desktop \
--to=matthewhughes934@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox