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

> Junio C Hamano <gitster@pobox.com> writes:
>
> > 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.
>
> The above "good way" is to notice and stop yourself from sending a
> patch that wants s->s.r to still exist.
>
> After that happens, it is tempting to rebuild your change on top of
> 'next'.  But please do *NOT* do so.
>
> Instead, identify such dependencies (i.e. other topics with changes
> relative to what 'master' has, that break what you developed
> directly on top of 'master'), and then merge them to 'master'
> yourself.  And then bulid your topic on top of the merge.  Work hard
> to limit your dependencies to absolute minimum, as these topics will
> take your work hostage---until they get merged down to 'master',
> your topic will not be able to be merged to 'master'.
>
> In this case, you'll be likely to do something like
>
>     $ git checkout -b sp/add-patch-with-fewer-the-repository origin/master
>     $ git merge --no-ff origin/ps-history-split
>     $ edit ... && git add ... && make test
>     $ git commit -m 'add-patch: use repository instance...'
>
> to build your single patch series on top of 'master' taken from my
> tree, with Patrick's history-split topic merged into it.
> After the commit is made, send out only your work (i.e., above the
> merge of Patrick's topic) to the list and you're done.
>