Re: [PATCH] add-patch: use repository instance from add_i_state instead of the_repository
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 17, 2026, 20:10 UTC
- Message-ID
- <xmqqse9yjjz9.fsf@gitster.g>
- In-Reply-To
- <20260317165230.628705-1-shreyanshpaliwalcmsmn@gmail.com>
Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> writes:
Show 20 quoted lines
>> > 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.