batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

[Eric Wong]

Taylor Blau <me@ttaylorr.com> wrote:
> * (Jonathan Tan) back to process isolation: is the short lifetime of the process
>   important?
> * (Taylor Blau) seems like an impossible goal to be able to do multi-command
>   executions in a single process, the code is just not designed for it.

-- Split out from https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/
Thanks for posting in an accessible format for non-JS/video users.

> * (Junio) is anybody using the `git cat-file --batch-command` mode that switches
>   between batch and batch-check.

I've started using --batch-command, but still have to test
backwards compatibility with git 2.35 to ensure users of older
git aren't left out.  I still try to support git 1.8.x, even...

But it would be nice if --batch-command grew more functionality:

* ability to add/remove alternates
* ability to specify a preferred alternate for a lookup[1]
* detect unlinked packs/removed repos

Not sure if cat-file is the place for it, but a persistent
process to deal with:

* `git config -f FILENAME ...' (especially --get-urlmatch --type=FOO)
* approxidate parsing for other tools[2]

Would also be nice...

Maybe I'll find the time and patience to implement this... *shrug*
Building C projects is pretty slow for me, even with -O0.

[1] I'm potentially dealing with 50-100k alternates, after all;
    and potentially config files in the 300-500k line range...

> * (Patrick Steinhardt) they are longer lived, but only "middle" long-lived.
>   GitLab limits the maximum runtime, on the order of ~minutes, at which point
>   they are reaped.
> * (Taylor Blau) lots of issues besides memory leaks that would become an issue
> * (Jeff Hostetler) would be nice to keep memory-hungry components pinned across
>   multiple command-equivalents.
> * (Taylor Blau): same issue as reading configuration.

sidenote: __attribute__((cleanup)) found in gcc + clang + tinycc
has greatly improved my life.  Perhaps only supporting Free software
compilers and cross-compiling for everything else is in order :P

The only gotcha I've noticed with ((cleanup)) is it doesn't fire
on longjmp, but that's not a problem for git.

I've also been abusing more Perl5 over the years as a code
generator and better CPP to make dealing with tedious tasks
more acceptable.


[2] I did recently license the code of a standalone C++ executable
    as GPL-2+ so I can copy approxidate parsing from git and
    perhaps figure out enough C++ to use Xapian query parser
    bindings instead of the hacky `git rev-parse --since=' thing
    I do.

Re: batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

[Junio C Hamano]

Eric Wong <e@80x24.org> writes:

> Taylor Blau <me@ttaylorr.com> wrote:
>> * (Jonathan Tan) back to process isolation: is the short lifetime of the process
>>   important?
>> * (Taylor Blau) seems like an impossible goal to be able to do multi-command
>>   executions in a single process, the code is just not designed for it.
>
> -- Split out from https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/
> Thanks for posting in an accessible format for non-JS/video users.
>
>> * (Junio) is anybody using the `git cat-file --batch-command` mode that switches
>>   between batch and batch-check.

This is not exactly what I asked about---I was asking about the use
of the "a long living process serves many requests" pattern ;-)

> But it would be nice if --batch-command grew more functionality:
>
> * ability to add/remove alternates
> * ability to specify a preferred alternate for a lookup[1]
> * detect unlinked packs/removed repos

To the third you would also want to notice an updated index, too.

> Not sure if cat-file is the place for it, but a persistent
> process to deal with:
>
> * `git config -f FILENAME ...' (especially --get-urlmatch --type=FOO)
> * approxidate parsing for other tools[2]
>
> Would also be nice...

"git daemon" ;-)?

Re: batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

[Jeff King]

On Tue, Oct 03, 2023 at 12:52:51AM +0000, Eric Wong wrote:

> Not sure if cat-file is the place for it, but a persistent
> process to deal with:
> 
> * `git config -f FILENAME ...' (especially --get-urlmatch --type=FOO)
> * approxidate parsing for other tools[2]
>
> [2] I did recently license the code of a standalone C++ executable
>     as GPL-2+ so I can copy approxidate parsing from git and
>     perhaps figure out enough C++ to use Xapian query parser
>     bindings instead of the hacky `git rev-parse --since=' thing
>     I do.

I know that you asked for a persistent process, but just for reference,
you can hackily access approxidate with:

  git config --type=expiry-date --default='15 days ago' does.not.exist

-Peff

Re: batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

[Eric Wong]

Jeff King <peff@peff.net> wrote:
> I know that you asked for a persistent process, but just for reference,
> you can hackily access approxidate with:
> 
>   git config --type=expiry-date --default='15 days ago' does.not.exist

--type is too new (trying to support 1.8.x :<).  But yeah, using
`git rev-parse --since=15.days.ago` and extracting the integers

Re: batch-command wishlist [was: [TOPIC 02/12] Libification Goals and Progress]

[Jeff King]

On Tue, Oct 03, 2023 at 08:31:24PM +0000, Eric Wong wrote:

> Jeff King <peff@peff.net> wrote:
> > I know that you asked for a persistent process, but just for reference,
> > you can hackily access approxidate with:
> > 
> >   git config --type=expiry-date --default='15 days ago' does.not.exist
> 
> --type is too new (trying to support 1.8.x :<).  But yeah, using
> `git rev-parse --since=15.days.ago` and extracting the integers

Ah, that is probably less hacky than my suggestion anyway.

-Peff