On Mon, Nov 02, 2020 at 09:43:21AM -0500, Jeff King wrote:
> 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
While Git should never segfault, no matter what, this is a bogus git
invocation to begin with: the second sentence in the description of
'git log -L' clearly states that "You may not give any pathspec
limiters", so this command should have errored out from early days,
but, unfortunately, it was never enforced. This also means that '-L'
and '--follow' are incompatible, because while the former forbids any
pathspecs, the latter requires exactly one; and line-level
log does its own rename following anyway.
VS Code should be fixed to call 'git log -L 1,1:hello.log' instead,
without '--follow' and without pathspec.
> > 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.
They shouldn't, I would say. Though it would be great if their
rename-following logic would be unified. In particular, line-level
log does a better job at rename following in some ways, notably it can
track multiple files at once, while '--follow' can only handle a
single file. So I think the rename following logic should be
extracted from 'line-log.c' and made more generic, and it should be
used to implement '--follow', removing some restrictions of the
latter, not to mention removing the duplicated logic.
(This might be a good GSoC project, though some of Linus' remarks in
750f7b668f (Finally implement "git log --follow", 2007-06-19) like
"you did have to know and understand the internal git diff generation
machinery pretty well, and had to really be able to follow how commit
generation interacts with generating patches and generating the log"
and "this patch does seem to be firmly in the core "Linus or Junio"
territory" are worrying...)
> 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. ;)
Perhaps, though arguably the original breakage was that 'git log
-L...:file -- file' was meant to error out, but it didn't.
