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

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

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.