From: Junio C Hamano <gitster@pobox.com>
To: Ben Knoble <ben.knoble@gmail.com>
Cc: Hardik Kumar <hardikxk@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] builtin: replace the_repository parameter in is_bare_repository()
Date: Thu, 27 Aug 2026 14:39:01 -0700 [thread overview]
Message-ID: <xmqqik4v6y6i.fsf@gitster.g> (raw)
In-Reply-To: <F276C11F-1904-496E-AA77-953724362C9A@gmail.com> (Ben Knoble's message of "Thu, 27 Aug 2026 17:12:19 -0400")
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.
> 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.
next prev parent reply other threads:[~2026-08-27 21:39 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 18:29 [PATCH] builtin: replace the_repository parameter in is_bare_repository() Hardik Kumar
2026-08-27 19:09 ` Junio C Hamano
2026-08-27 19:51 ` Junio C Hamano
2026-08-27 20:09 ` Hardik Kumar
2026-08-27 20:28 ` Junio C Hamano
2026-08-27 21:12 ` Ben Knoble
2026-08-27 21:39 ` Junio C Hamano [this message]
2026-08-28 11:41 ` D. Ben Knoble
2026-08-28 22:51 ` Junio C Hamano
2026-08-28 22:51 ` [PATCH 0/8] More sensible checkout/switch/restore code refactoring Junio C Hamano
2026-08-28 22:51 ` [PATCH 1/8] checkout: pass cb_option explicitly to branch name parsers Junio C Hamano
2026-08-28 22:52 ` [PATCH 2/8] checkout: validate new branch name in checkout_branch() Junio C Hamano
2026-08-28 22:52 ` [PATCH 3/8] checkout: validate stage and merge option compatibility in checkout_paths() Junio C Hamano
2026-08-28 22:52 ` [PATCH 4/8] checkout: extract option validation and pathspec helpers Junio C Hamano
2026-08-28 22:52 ` [PATCH 5/8] checkout: extract branch setup and tracking helpers Junio C Hamano
2026-08-28 22:52 ` [PATCH 6/8] checkout: restructure switch, restore, and checkout entrypoints Junio C Hamano
2026-08-28 22:52 ` [PATCH 7/8] checkout: wrap overly long lines Junio C Hamano
2026-08-28 22:55 ` Junio C Hamano
2026-08-29 2:06 ` Junio C Hamano
2026-08-28 22:52 ` [PATCH 8/8] checkout: move post_checkout_hook() to checkout.c Junio C Hamano
2026-08-28 22:57 ` Junio C Hamano
2026-08-29 2:05 ` Junio C Hamano
2026-08-30 20:48 ` [PATCH v2 0/8] More sensible checkout/switch/restore code refactoring Junio C Hamano
2026-08-30 20:48 ` [PATCH v2 1/8] checkout: pass cb_option explicitly to branch name parsers Junio C Hamano
2026-09-01 11:31 ` Karthik Nayak
2026-08-30 20:48 ` [PATCH v2 2/8] checkout: validate new branch name in checkout_branch() Junio C Hamano
2026-09-01 11:36 ` Karthik Nayak
2026-08-30 20:48 ` [PATCH v2 3/8] checkout: validate stage and merge option compatibility in checkout_paths() Junio C Hamano
2026-09-01 11:53 ` Karthik Nayak
2026-09-01 17:47 ` Junio C Hamano
2026-09-02 11:20 ` Karthik Nayak
2026-09-02 22:40 ` Junio C Hamano
2026-09-03 9:21 ` Karthik Nayak
2026-08-30 20:48 ` [PATCH v2 4/8] checkout: extract option validation and pathspec helpers Junio C Hamano
2026-08-30 20:48 ` [PATCH v2 5/8] checkout: extract branch setup and tracking helpers Junio C Hamano
2026-08-30 20:48 ` [PATCH v2 6/8] checkout: restructure switch, restore, and checkout entrypoints Junio C Hamano
2026-09-01 14:14 ` Karthik Nayak
2026-09-01 23:25 ` Junio C Hamano
2026-09-02 11:02 ` Karthik Nayak
2026-08-30 20:48 ` [PATCH v2 7/8] checkout: wrap overly long lines Junio C Hamano
2026-08-30 20:48 ` [PATCH v2 8/8] checkout: move post_checkout_hook() to checkout.c Junio C Hamano
2026-08-29 13:24 ` [PATCH] builtin: replace the_repository parameter in is_bare_repository() D. Ben Knoble
2026-08-27 21:35 ` [PATCH] do not pass "repo" to builtin commmand implementations Junio C Hamano
2026-08-28 9:05 ` Hardik Kumar
2026-08-28 20:59 ` Junio C Hamano
2026-08-28 4:01 ` [PATCH] builtin: replace the_repository parameter in is_bare_repository() Hardik Kumar
2026-08-27 19:56 ` Hardik Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqik4v6y6i.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=hardikxk@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox