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.
> 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.
> 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.
> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html