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

[Fengguang Wu]

On Tue, Feb 23, 2016 at 10:30:04PM -0800, Junio C Hamano wrote:
> Fengguang Wu <fengguang.wu@xxxxxxxxx> writes:
> 
> > 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.

> > 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