[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xmqqpovmmxhv.fsf@gitster.mtv.corp.google.com>
Date: Tue, 23 Feb 2016 22:30:04 -0800
From: Junio C Hamano <gitster@...ox.com>
To: Fengguang Wu <fengguang.wu@...el.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Xiaolong Ye <xiaolong.ye@...el.com>, git@...r.kernel.org,
ying.huang@...el.com, philip.li@...el.com, julie.du@...el.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Christoph Hellwig <hch@....de>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info
Fengguang Wu <fengguang.wu@...el.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).
> 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
database are using the --stable version of the patch-id for indexing
the patches)? 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.
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. 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).
Powered by blists - more mailing lists