Re: [PATCH] builtin: replace the_repository parameter in is_bare_repository()

From: Ben Knoble <ben.knoble@gmail.com>
Date: Aug 27, 2026, 21:12 UTC
Message-ID: <F276C11F-1904-496E-AA77-953724362C9A@gmail.com>
In-Reply-To: <xmqq7blb8g04.fsf@gitster.g>

Show 9 quoted lines

> Le 27 août 2026 à 16:30, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> "Hardik Kumar" <hardikxk@gmail.com> writes:
> 
>>> In general, builtin/foo.c::cmd_foo() are concrete programs that work
>>> on specific repository (i.e., the_repository), and there is not much
>>> reason to rewrite the use of the_repository to use "repo" given by
>>> the caller which is git potty.  You'd also need to deal with the
>>> case where "repo" is NULL (hint: "cd / && git foo -h").

[snip]

Show 7 quoted lines

> The utility functions builtin/foo.c borrows from outside builtin/
> directory are being "libified" to reduce the hardcoded dependence on
> the_repository, and cmd_foo() can call these functions with
> the_repository as a parameter.  But we have no reason to waste our
> time updating (and also reviewing patches that make such updates)
> the built-in implementations themselves to take a pointer to an
> arbitrary repository.

Hm. What if a program wants to do « exactly what ‘git switch’ does » sans shelling out? It’d be a maintenance burden to answer « open code it using helpers in libgit and the builtin sources », at least as presented. Many builtin sources seem (at least to me) quite complex! And it’s not immediately obvious how I could recreate the intended effects of, say, « switch branches » with just one or 2 libgit calls. (Maybe that’s just me.)

In other words, the stance « it’s not worth it to libify builtins » only makes sense if we also say « we don’t explicitly support precisely replicating builtin behavior via libgit ».

Which is fine! I’m probably just not aware if there was discussion/consensus on that somewhere. Pointers welcome :)

(I for one think it would be nice to have the ability to call a builtin directly through libgit, or at least think through what organization of code would be necessary to make it feasible to say « to do builtin X, you need only call these 5 lib functions in sequence with your choice of arguments »—since perhaps parseopt’ing isn’t so relevant at that level—but I lack a concrete use case at the moment.)