Messages in this thread | | | Date | Wed, 24 Feb 2016 15:07:27 +0800 | From | Fengguang Wu <> | Subject | 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 <fengguang.wu@intel.com> 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
| |