Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On Tue, Feb 23, 2016 at 10:30:04PM -0800, Junio C Hamano wrote:

Fengguang Wu [off-list ref] writes:

quoted

The necessary lines for the robot are

        base commit:
        base patch-id:
or
        base tree-id:
        base patch-id:

I will not repeat why a commit object name would be more appropriate
than a tree object name here (please see my response to HPA).

Yes I see that reasoning in your other email.

quoted

The "base tree-id" will be useful if the submitted patchset is based
on a public (maintainer) commit.

The "base patch-id" will be useful if the submitted patchset is based
on another patchset someone (likely the developer himself) posted to
the mailing list.

Is there a database of in-flight patches indexed by their patch-ids
with a large enough coverage (hopefully those who maintain such a

Yes, the 0day robot internally maintains such a patch-id => commit-id
(of the below git tree) database for in-flight patches.

We exported a git tree which holds all in-flight patches, where each
patchset maps to a new branch:

https://github.com/0day-ci/linux/branches

We monitor dozens of linux kernel mailing lists, the coverage is
pretty good for the linux kernel project.

database are using the --stable version of the patch-id for indexing
the patches)?

Right, we do use the --stable option.

I am wondering how well this scales, especially if a
well-known commit named by "base commit" needs to be checked out and
then many in-flight patches identified by "base patch-id"s need to
be applied on top of it, to prepare the tree-ish the patch being
evaluated can be applied to.

The database is effectively a key-value store, in the scale of 1000
new mappings per day. If we only keep 100 days data, there will be
100k mappings, which could be hold in 10MB memory.

This starts to sound more like something you would want to write in
the cover letter, or the trailer block next to Signed-off-by: at the
end of the first patch in the series.

Yes, that's roughly what the current patch does, except in the latter
case we add new info after diffstat.

Or even after the mail
signature at the very end of the message (incidentally that would
probably minimize the damage to the Git codebase needed for this
addition--you should be able to do this without touching anything
other than builtin/log.c).

That's an interesting place. It looks worth trying. 

Thanks,
Fengguang