Re: Segfault in git when using git logs

From: Jeff King <peff@peff.net>
Date: Nov 3, 2020, 18:21 UTC
Message-ID: <20201103182102.GA459792@coredump.intra.peff.net>
In-Reply-To: <20201103101553.GH24813@szeder.dev>

On Tue, Nov 03, 2020 at 11:15:53AM +0100, SZEDER Gábor wrote:

Show 12 quoted lines

> > > 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.

Thanks for confirming. My "I am not clear how these should interact" was really "this does not make any sense to me" in my head, but I was afraid that I was missing something. The fact that we document explicitly that -L should not be combined with pathspecs makes that much more obvious.

> VS Code should be fixed to call 'git log -L 1,1:hello.log' instead,
> without '--follow' and without pathspec.

Agreed.

On our side, I don't think it would be _wrong_ to catch and disallow the combination. But it may be nicer to them if we continue to quietly ignore --follow and the pathspec in that case, for working with older versions. (OTOH, if I understand correctly they're segfaulting every time VS Code is used with v2.29 now, so they may have to accept it as an urgent fix anyway).

-Peff