threads / discuss / 60291

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

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

## tl;dr

5 messages between Oct 3, 2023 and Oct 3, 2023.

replies: 4people: 3as markdown or json

Eric Wong· Oct 3, 2023, 00:52 UTC · lore
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...
Show 7 quoted lines
> * (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.
Junio C Hamano· Oct 3, 2023, 16:15 UTC · re: Eric Wong · lore

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

Eric Wong <e@80x24.org> writes:
Show 11 quoted lines
> 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 ;-)

Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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" ;-)?
Jeff King· Oct 3, 2023, 20:10 UTC · re: Eric Wong · lore

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

On Tue, Oct 03, 2023 at 12:52:51AM +0000, Eric Wong wrote:
Show 11 quoted lines
> 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
Eric Wong· Oct 3, 2023, 20:31 UTC · re: Jeff King · lore

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

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

Jeff King· Oct 3, 2023, 20:32 UTC · re: Eric Wong · lore

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

On Tue, Oct 03, 2023 at 08:31:24PM +0000, Eric Wong wrote:
Show 8 quoted lines
> 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

← back to recent threads