]> git.ipfire.org Git - thirdparty/git.git/commitdiff
diff: ignore unmerged paths outside prefix with --relative --cached
authorJeff King <peff@peff.net>
Wed, 15 Jul 2026 06:05:23 +0000 (02:05 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 15 Jul 2026 18:33:50 +0000 (11:33 -0700)
A diff using --relative ignores entries outside the current directory.
This results in a segfault when we try to process an unmerged entry
that's outside of our prefix, since we end up with a NULL diff_filepair
and use it without checking that it's valid.

I think this bug goes back to 76399c0195 (diff.c: return filepair from
diff_unmerge(), 2011-04-22). Prior to that, diff_unmerge() knew to skip
entries outside of our prefix, due to cd676a5136 (diff --relative:
output paths as relative to the current subdirectory, 2008-02-12). Back
then the caller didn't care that we hadn't added anything to the queue.
In 76399c0195 that changed; we now returned the pair (or NULL), and the
caller in do_oneway_diff() was then called fill_filespec() itself. And
it does so without checking for NULL, causing a segfault.

The obvious fix is to skip the fill_filespec() call (after which we just
return), which this patch does.

There's another call to diff_unmerge() in run_diff_files(). That case
was already fixed by 8174627b3d (diff-lib: ignore paths that are outside
$cwd if --relative asked, 2021-08-22), but of course it didn't help us
for --cached.

That commit also claims that checking the result of diff_unmerge() is
not enough, as we'd want other code paths to skip the entry, too (even
if they wouldn't segfault). But as far as I can tell, that is not true
for --cached. We eventually end up in diff_queue_addremove() or in
diff_queue_change(), both of which know to return early when we're
outside of the prefix.

Arguably we could be checking at the top of oneway_diff() whether the
path is interesting at all. That would not only avoid this code path
entirely, but would also possibly save a small amount of work. But since
everything else appears to work OK, I went for the smallest fix here to
avoid any regression.

Specifically, a comment in oneway_diff() claims we're supposed to
advance o->pos, which we might fail to do if we return early. Though
that "advance" seems to have gone away in da165f470e (unpack-trees.c:
prepare for looking ahead in the index, 2010-01-07), so it is possible
the comment is simply out of date.  We can explore that separately;
checking for a NULL return from diff_unmerge() seems like a sensible
thing to do regardless.

We can piggy-back on the tests added by 8174627b3d; we're just checking
the --cached variant.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-lib.c
t/t4045-diff-relative.sh

index ae91027a024eece23f0f1ede20467eeb425a2b3b..a23119b852201270fe2b4e7e91cb726d1ed3249b 100644 (file)
@@ -467,7 +467,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
        if (cached && idx && ce_stage(idx)) {
                struct diff_filepair *pair;
                pair = diff_unmerge(&revs->diffopt, idx->name);
-               if (tree)
+               if (pair && tree)
                        fill_filespec(pair->one, &tree->oid, 1,
                                      tree->ce_mode);
                return;
index 2c8493fe66c441b23d11c8ed1048d3a92e3937e8..167be0bdcce586253de6a695d95c17f552544558 100755 (executable)
@@ -245,4 +245,13 @@ test_expect_failure 'diff --relative with change in subdir' '
        test_cmp expected out
 '
 
+test_expect_success 'diff --relative --cached with change in subdir' '
+       git switch br3 &&
+       test_when_finished "git merge --abort" &&
+       test_must_fail git merge sub1 &&
+       echo file0 >expected &&
+       git -C subdir diff --relative --name-only --cached >out &&
+       test_cmp expected out
+'
+
 test_done