From: Junio C Hamano Date: Tue, 17 Mar 2026 20:10:02 GMT Subject: Re: [PATCH] add-patch: use repository instance from add_i_state instead of the_repository Message-ID: In-Reply-To: <20260317165230.628705-1-shreyanshpaliwalcmsmn@gmail.com> Shreyansh Paliwal 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 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 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 Signed-off-by: Junio C Hamano 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.