Re: [PATCH v1] builtin/mktree: remove USE_THE_REPOSITORY_VARIABLE

[Tian Yuchen <cat@malon.dev>]

Hi Junio,

> Tian Yuchen <cat@malon.dev> writes:
> 
>> On 3/14/26 01:54, Junio C Hamano wrote:
>> 
>>> I strongly disagree your idea that 'z' is more business logic than
>>> 'h' is.  Both are equally relevant.
>> 
>> Perhaps I didn't explain myself clearly :(
>> 
>> I do understand that *currently* both are part of the business logic.
>> However, what puzzles me is: why is it written this way? Why isn't -h
>> intercepted at the outer global level, but instead handed off to a
>> function like parse_options() for interception?
>> 
>> Is this due to historical reasons?
>> 
>> Please forgive my slowness. I would appreciate it if you could offer
>> some guidance!
> 
> It is perfectly OK to be slow.  Spend enough time to study the code
> so that you do not have to ask for forgiveness ;-)
> 
> In order to make a useful response to "-h", that business logic
> needs to know what options are available and what argument they take
> etc., which is already given to parse_options API.  What makes it
> make any sense to split it to separate codepath?

I see.

I’ve been thinking about it, and moving it to an external file seems
to break encapsulation also. If 'option[]' is no longer static, then the 
code
that originally handled this logic would have to be moved to a file like
'git.c', and the codebase would increase significantly. That’s probably
not what we want, right?

This is not only semantically confusing, but it also doesn't work any
better in practice.

I kept thinking about maintaining a separate framework to intercept
all of this — I guess I’ve fallen into a certain mindset when it comes 
to
modern CLIs. These changes, which do not offer any significant 
advantages,
seem to actually undermine performance and local clarity. It really 
isn’t
worth the effort.

I hadn't actually planned to migrate anything. I was just a bit confused 
as
to why it was written this way.

Thank you,

Yuchen