On Tue, Feb 23, 2016 at 10:30:04PM -0800, Junio C Hamano wrote: > Fengguang Wu <fengguang...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
