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

>
> "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.