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

From: Fengguang Wu <fengguang.wu@intel.com>
Date: Feb 24, 2016, 02:55 UTC
Message-ID: <20160224025519.GB16562@wfg-t540p.sh.intel.com>
In-Reply-To: <20160223133135.GF5273@mwanda>

On Tue, Feb 23, 2016 at 04:31:35PM +0300, Dan Carpenter wrote:

> Blergh...  You want it machine readable and I want it human readable.  I

Yeah. It's kind of tasting which may differ among people. I'll leave the judgments to Junio and others, and only add necessary comments to your points.

Show 8 quoted lines

> don't care so much about the cover letter but for the first patch then I
> really want something minimal (one line) and human readable.
> 
> base tree/branch: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> base commit: afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
> base patch-id: a849260a843115dbac4b1a330d44256ee6b16d7b
> base patch-subject: Linux 4.4
> base tag: v4.4

The necessary lines for the robot are

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

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.

Show 11 quoted lines

> To me that looks like an unparseable wall of text.  My version of that
> is:
> 
> Applies-to: afd2ff9b7e1b+ origin
> 
> As a human all I really want to know is the tree to apply this to.  If
> it doesn't apply then I don't debug it, I just send an automatic note
> "This doesn't apply to staging-next.  Please redo."
> 
> I think that Applies-to is a better name and also that grepping for
> "^base " is less reliable than grepping for ^Applies-to.

Grep reliability should be the same, if you use "^base tree-id" and "^base patch-id". If necessary, we can avoid white space by naming the keys base-tree-id and base-patch-id.

Show 5 quoted lines

> I used "origin" because that's the name in Next/Trees.  The + means
> private patches are applied.  That's what we already do in naming the
> kernel.  If the + matters, then I would include a cover letter.
> 
> I have no idea what a "base patch-id" is so that doesn't work at all.

It'll come from this command

        man git patch-id

It'll be useful if the patchset's base commit is a private one -- not in any public maintainer tree, however the developer may have posted it to LKML before.

The "base patch-id" can more reliably track different versions of patches than "base patch-subject", and do not have the risk of information leaking in case it's a confidential patch.

> Including the tag is just duplicative since we already have the hash.

That's right. Just in case it's more human readable.

> In my email, I proposed that we list all the other private patches in a
> cover letter, but I think you are saying that we only need to know the
> most recent private patch?

Yes in test robot POV. However it's a general git feature, so I guess there will be more potential use cases and requirements.

Show 7 quoted lines

> Another idea would be to list them newest
> to oldest (git log order instead of email order) in the cover letter.
> 
> Btw, I always work against linux-next and Dave M is always getting
> annoyed with me for not marking which patches go to net and which go to
> net-next.  I don't use git format-patch, but I will probably start using
> "Applies-to: net" or "Applies-to: net-next".

As for now, I see the netdev ML has the convention

        [PATCH net]
        [PATCH net-next]

to tell Dave the target tree.

Thanks, Fengguang