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

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Aug 28, 2026, 11:41 UTC
Message-ID: <CALnO6CCsJGmgmvKyMdX3q1Kr5AnBwYJ=_UiQ9+m7jWe7hv=3Qw@mail.gmail.com>
In-Reply-To: <xmqqik4v6y6i.fsf@gitster.g>

On Thu, Aug 27, 2026 at 5:39 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 24 quoted lines

>
> Ben Knoble <ben.knoble@gmail.com> writes:
>
> >> 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]
> >
> >> 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.
>
> Line wrap to reasonable length.

Yeah… my iPhone (from which I sometimes reply) supports plaintext if I do things just right, but it doesn't wrap lines. It's difficult to judge where to break, but maybe I'll try hardbreaks every so often and see if that helps.

Show 11 quoted lines

> > Hm. What if a program wants to do « exactly what ‘git switch’ does
> > » sans shelling out?
>
> Instead of cheating, properly factor out reusable part from
> cmd_checkout() into a set of libified routines, and make both
> cmd_checkout() and cmd_switch() to call them
>
> An approach like that would help "libify" things.  libifying is not
> just reducing dependence of globals.
>
> Calling main() from something else is not a libification.

Sensible. Thanks!

-- 
D. Ben Knoble