Re: [PATCH] t1500: ensure current --since= behavior remains

[Eric Wong <e@80x24.org>]

Jeff King <peff@peff.net> wrote:
> On Wed, Feb 10, 2021 at 09:55:43PM +0000, Eric Wong wrote:
> 
> > This behavior of git-rev-parse is observed since git 1.8.3.1
> > at least(*), and likely earlier versions.
> > 
> > At least one git-reliant project in-the-wild relies on this
> > current behavior of git-rev-parse being able to handle multiple
> > --since= arguments without squeezing identical results together.
> > So add a test to prevent the potential for regression in
> > downstream projects.
> 
> I had to read this a few times to understand what "this behavior" meant.
> It is just: when given multiple --since options, output a --max-age for
> each of them, even though internally, Git's revision traversal will only
> use one (in the usual last-one-wins fashion).
> 
> I'm not sure if I was just being dense, or if this could be spelled out
> more clearly. :)

*shrug* :>  My brain struggles with coherent thought so I'm
surprised anybody is able to understand me at all :x

> Out of curiosity, why does the other project want that? From your
> mention of libgit2's git__date_parse(), I assume it's something that
> wants to parse approxidates into timestamps in a script. Maybe we ought
> to provide a more direct and robust way of doing that. We have a similar
> need in t0006, but we use a test-helper program for it.

It takes about 5ms for my system to run git-rev-parse once.  I
may be getting multiple approxidates at once, 1-2 in a typical
input (start..end); but a strange or malicious input could have
hundreds/thousands of approxidates to parse.

Thus, I'm batching up all the approxidates into one rev-parse
invocation (up to system argv limits right now).  With the
output lines split into an array, walking the output/input
arrays in parallel will match them up.  Hypothetically, if
rev-parse were to get clever and deduplicate or reject identical
inputs; then the parallel walk would be broken.

> (I have no problem in the meantime with this patch, though; any new
> method for accomplishing this would want to give other projects time to
> adapt to its use).

Yes.  I think I've mentioned some years/decade ago having
general functionality along the lines of "git cat-file --batch"
or fast-import would be nice (even for some existing scripts and
tests shipped with git).  (v)fork+execve is painful even on
Linux.