Re: [PATCH v2 0/5] Introduce 'uploadpack.lazyFetchTrusted'

On Thu, Aug 13, 2026 at 10:31 PM Junio C Hamano <[email protected]> wrote:
>
> Christian Couder <[email protected]> writes:
>
> > Recently the "promisor-remote" capability was added to protocol v2,
> > allowing servers and clients to agree on the promisor remotes they can
> > safely use.
>
> I do not know what you did, but it seems that an attempt to futz
> with the thread structure i.e.,
>
>     This version is also sent as a separate 'v2' iteration in reply to v1,
>     instead of being threaded onto the previous "Introduce a
>     'fromAccepted' option to GIT_NO_LAZY_FETCH" series, and it now
>     contains a 'base-commit' trailer, so that 'b4' and other tools can
>     find the right base and the right patches.
>
> made the patches totally unusable.
>
> This [v2 0/5] has
>
>     Message-ID: <[email protected]>
>     In-reply-to: <[email protected]>
>
> which is *correct*.  It is a reply to [0/5] of the original thread.
> However, [v2 1/5] says:
>
>     Message-ID: <[email protected]>
>     In-reply-to: <[email protected]>
>
> which is quite wrong.  [v2 1/5] should be a reply to the cover
> letter of the v2 iteration.  [v2 2/5], [v2 3/5], ... should also be
> replies to the cover letter of the v2 iteration.

Yeah, sorry. I tried to pass `--in-reply-to` to `git format-patch`
instead of `git send-email` but it looks like they don't behave the
same. Maybe because I have no `format.thread` set, so `git
format-patch` defaults to `--no-thread`, and in that case
`--in-reply-to` applies to every mail, not just the cover letter. I
should have checked more carefully and not tried to improve too many
things at once in my setup.

> I have never seen either plain vanilla send-email or GitGitGadget
> produce misthreaded series like this one.  Do you have some custom
> settings to send things out?

No, I just use `git format-patch` and `git send-email` without special
configuration.

> Here is _one_ way to create a thread of the right shape:
>
>  1. Develop this 5-patch series.
>
>  2. Run
>
>     $ git format-patch -v2 --cover-letter -5
>
>     to grab 0000-cover-letter.patch to 0005-builtin-upload-...patch
>     files.  You may also want to pass --range-diff option.
>
>  3. Edit 0000-cover-letter.patch to your satisfaction.  Do not futz
>     with In-Reply-To or References or Message-Id yourself there;
>     the tool will do this part better than manual editing.
>
>  4. Run
>
>     $ git send-email --no-chain-reply-to \
>       --in-reply-to='<[email protected]>' \
>       000[0-5]-*.patch

Yeah, that's pretty much what I usually do. I don't use
`--no-chain-reply-to` though, but I will.

>     This will make the initial message (which is the cover letter of
>     this iteration) a reply to the named message (which is the cover
>     letter of the v1 iteration), and then the remainder replies to
>     the initial message, which is what we want to see.
>
> There surely are other right ways to do so.  As long as the end
> result would look like
>
>     * vN (1 < N) cover letter is a reply to v1 cover letter
>     * vN patch M (0 < M) is a reply to vN cover letter

Yeah I should have checked more carefully before sending. Thanks.

> things will flow more smoothly.
>
> HTH.