From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 17 Mar 2026 20:25:34 GMT
Subject: Re: [PATCH] add-patch: use repository instance from add_i_state instead of the_repository
Message-ID: <xmqqo6kmjj9d.fsf@gitster.g>
In-Reply-To: <xmqqse9yjjz9.fsf@gitster.g>

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.

Thanks.