On Mon, Nov 02, 2020 at 03:59:59PM +0200, Sathyajith Bhat wrote:
> Simple repro steps
>
> mkdir git_segfault_test && cd git_segfault_test && echo
> "Hello" > hello.log
> git init && git add hello.log && git commit -m "init commit"
>
> Now, use git log to show commit logs using command
>
> git log --follow -L 1,1:hello.log -- hello.log
>
> What did you expect to happen? (Expected behavior)
> Git should not segfault
Thanks for making this reproduction recipe! I can easily see the problem
on my system. Looks like the segfault was introduced by a2bb801f6a
(line-log: avoid unnecessary full tree diffs, 2019-08-21). I've cc'd the
author.
That commit causes the line-log to clear the set of pathspecs, but the
--follow option requires exactly one pathspec (and it even makes sure
the user gives us one, but that happens before we clear it internally).
Something like this makes the segfault go away:
diff --git a/line-log.c b/line-log.c
index 42c5e41f68..f789863928 100644
--- a/line-log.c
+++ b/line-log.c
@@ -847,6 +847,7 @@ static void queue_diffs(struct line_log_data *range,
clear_pathspec(&opt->pathspec);
parse_pathspec_from_ranges(&opt->pathspec, range);
}
+ opt->flags.follow_renames = 0;
DIFF_QUEUE_CLEAR(&diff_queued_diff);
diff_tree_oid(parent_tree_oid, tree_oid, "", opt);
if (opt->detect_rename && diff_might_be_rename()) {
but I'm not clear on how "--follow" and "-L" are supposed to interact. I
wouldn't expect --follow to do anything at all with line-log (nor for it
to be useful to specify pathspecs outside of the -L option). So possibly
this is restoring the behavior prior to that commit, or possibly it's
just papering over a breakage. ;)
-Peff
