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

[Junio C Hamano <gitster@pobox.com>]

"D. Ben Knoble" <ben.knoble@gmail.com> 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.