public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail•com>
To: git@vger•kernel.org
Cc: gitster@pobox•com
Subject: Re: [PATCH] add-patch: use repository instance from add_i_state instead of the_repository
Date: Wed, 18 Mar 2026 12:31:20 +0530	[thread overview]
Message-ID: <20260318070237.659845-1-shreyanshpaliwalcmsmn@gmail.com> (raw)
In-Reply-To: <xmqqo6kmjj9d.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 a lot for this useful tip.
Going forward, I will first try to ensure that there are no on-going
conflicting patches by a trial merge to seen/next branch. Then after
if there are any I would merge those dependent patches locally on a
copy of master, thereafter build my changes on that and send them.

Best,
Shreyansh

next prev parent reply	other threads:[~2026-03-18  7:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 15:50 [PATCH] add-patch: use repository instance from add_i_state instead of the_repository Shreyansh Paliwal
2026-03-17 16:47 ` Junio C Hamano
2026-03-17 16:51   ` Shreyansh Paliwal
2026-03-17 18:04     ` Junio C Hamano
2026-03-17 20:10     ` Junio C Hamano
2026-03-17 20:25       ` Junio C Hamano
2026-03-18  7:01         ` Shreyansh Paliwal [this message]
2026-03-18  9:00 ` [PATCH v2 ] add-patch: use repository instance from add_p_state " Shreyansh Paliwal
2026-03-18 16:43   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260318070237.659845-1-shreyanshpaliwalcmsmn@gmail.com \
    --to=shreyanshpaliwalcmsmn@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox