Re: Linking topic merges to mailing list threads

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 30, 2024, 19:30 UTC
Message-ID: <xmqqv7yd548i.fsf@gitster.g>
In-Reply-To: <CAJoAoZ=4ARuH3aHGe5yC_Xcnou_c396q_ZienYPY7YnEzZcyEg@mail.gmail.com>

Emily Shaffer <nasamuffin@google.com> writes:

Show 8 quoted lines

> We've been wanting to gather metrics on Git's code review process -
> how long it takes from first contact on list to merge, how many
> iterations are needed, time between iterations, etc. One missing link
> is the actual merge time in `next` and `master` - a human can infer
> the link between the patch and the mailing list thread, but it's more
> challenging for a script to do it.
>
> Would it be possible to modify the maintainer workflow ...

I suspect that there is no need for any workflow change, as all the necessary information should be available from public sources.

The first-parent chain from 'next' (or 'master' for that matter) already record when they got merged. From there, C^1..C^2 are the commit objects that were merged. notes/amlog knows where they came from (i.e. their Message-Id). From lore/public-inbox you can find out how the iterations of topics went, as long as the topics are threaded properly (and if not, that would not be fixable with any maintainer workflow changes), just like how b4 can figure all of that out.

Ahh, nothing officially documents amlog and that is what you are missing. It would be very nice if somebody, preferrably somebody other than I, after trying the "maintainer workflow" by pretending to be a maintainer for a day or two with the new info revealed here, updates the Documentation/howto/maintain-git.txt file with the information below.

The script post-appplypatch found in the todo branch is made available as .git/hooks/post-applypatch so that "git am" knows to run it after creating a commit out of an e-mailed patch. It populates a mapping from commit object name to "Message-Id" of individual patch.

"git rebase" knows how to propagate this across rebases because I have

    [notes] rewriteref = refs/notes/amlog

in the .git/config (which means I have to use rebase not cherry-pick even when I am touching a single patch, as cherry-pick does not preserve notes by design).

Now I think you should have everything, together with what is already in Documentation/howto/maintain-git.txt, piece them together to illustrate the life of a patch series.

As I do not publish reflog for 'seen', you cannot do "when was the topic got picked up to 'seen'?", but as far as I am concerned, it is by design. Being in 'seen' does not mean anything other than I happened to have seen it, or saw that somebody indicate interest in it.

Thanks.