From: Junio C Hamano Date: Fri, 28 Aug 2026 22:51:00 GMT Subject: Re: [PATCH] builtin: replace the_repository parameter in is_bare_repository() Message-ID: In-Reply-To: "D. Ben Knoble" writes: >> > 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! I actually answered a wrong question though ;-) The way cmd_switch() and cmd_restore() were introduced by sharing what used to serve cmd_checkout() was serviceable, but ugly. Had we started from separate implementations for 'switch' and 'restore' that were later merged into 'checkout', we would not have ended up with a design centered on a single monolithic choke point like checkout_main(). That is what I meant by "cheating instead of refactoring reusable parts". However, that is not directly relevant to your example. It is an anti-pattern to call the top-level implementation of 'git foo' in cmd_foo() directly from cmd_bar(), since these cmd_foo() functions are like main() in ordinary programs, performing one-time initialization (such as git_config() calls) and finalization that cannot be repeated. To help our codebase, as well as the use case you imagined in your message, it would help to trim down these non-reusable cmd_foo() implementations by turning them into mere orchestrators that call refactored helper functions. Such a change would put cmd_foo() and a client that wants to reuse 'git switch' functionality on the same footing, allowing more of our code to be used in different contexts. I think that is what people mean by the "libification" effort.