Re: [PATCH] add-patch: use repository instance from add_i_state instead of the_repository

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

Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:

>> > Functions parse_diff(), edit_hunk_manually() and patch_update_file() use
>> > the_repository even though a repository instance is already available via
>> > struct add_i_state s which is defined in struct add_p_state *s.
>> >
>> > Use 's->s.r' instead of the_repository to avoid relying on global state. All
>> > callers pass a valid add_p_state and this does not change any behavior.
>> >
>> > This aligns with the ongoing effort to reduce usage of the_repository global
>> > state.
>>
>> So we can call this "reduce" but cannot say "eliminate" yet, as the
>> files uses comment_line_str?
>>
>> The <environment.h> header lists some global variables inside
>> "#ifndef USE_THE_REPOSITORY_VARIABLE/#endif" block, and the
>> comment-line stuff is among them.
>>
>
> Yes that's right, there is an instance of comment_line_str, should I add this
> in the commit message and send a reroll ?

Having said that, please make sure your patch works well with
patches others are working on.  In this case, s->s.r would no longer
exist after this one:

commit d51b61f5dab9c8e715fa792f31d572bc96fb5687
Author: Patrick Steinhardt <ps@pks.im>
Date:   Mon Mar 2 13:13:07 2026 +0100

    add-patch: remove dependency on "add-interactive" subsystem
    
    With the preceding commit we have split out interactive configuration
    that is used by both "git add -p" and "git add -i". But we still
    initialize that configuration in the "add -p" subsystem by calling
    `init_add_i_state()`, even though we only do so to initialize the
    interactive configuration as well as a repository pointer.
    
    Stop doing so and instead store and initialize the interactive
    configuration in `struct add_p_state` directly.
    
    Signed-off-by: Patrick Steinhardt <ps@pks.im>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

A good way to ensure that you do not send a patch that does not work
well with others is to make a trial merge to 'next' and 'seen' and
ensure that they produce working Git, after making sure your patch
applied directly on top of 'master' works well.

Thanks.