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

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.

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?

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

    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

things will flow more smoothly.

HTH.