All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 4.15-1
Date: Mon, 20 Nov 2017 21:48:58 -1000	[thread overview]
Message-ID: <CA+55aFx0=yO7=LaJFeDQ6MthtXYSFSAzO4gpQ6EbFwVgjRqMGA@mail.gmail.com> (raw)
In-Reply-To: <20171120190602.GD379@fury>

On Mon, Nov 20, 2017 at 9:06 AM, Darren Hart <dvhart@infradead.org> wrote:
>
> Back in the 4.2 timeframe, platform-drivers-x86-v4.2-2 specifically, I
> started adding my pull request commentary to the tag directly and the
> pull requests themselves tended to have little or no information beyond
> that.

Right - that's fine. I don't actually care whether the information is
in the signed tag, or in the emailed pull request, or in both. I'll
take it either way.

There are valid reasons to put it in the signed tag - that way you
write it as you do the tag, and then "git pull-request" is pretty much
entirely just automation.

But some people prefer to do the tag as just a marker (so the tag
message may be basically worthless), and then write the explanation
later in the email as they send it off. And that's fine too.

And yet other people do both - write some summary in the tag, but hen
write more about it in the emailed message. And I'll take that too, no
problem.

And in all three cases I'll edit things for grammar and whitespace
(indentation) etc, and may remove commentary that may be interesting
for  me doing the merge, but isn't relevant in the history once the
merge is done.

> I didn't see a clear division between what should go in the pull
> request email body and what should be in the tag, this kept all the
> information about the pull request together in the tag.

There really is no division at all. One common _pattern_ is to have
the email message contain more of a freeform message, while the tag
contains more of a "summary list", but that's just a pattern that some
people tend to use, and it's not in any way universal or required.

> Andy's pull request follows this pattern, with the text of the tag
> opening with the summary and context relevant to the pull request before
> the munged shortlog:

Yes, and that separation is fine.

But I do want both parts to make sense. If the munged shortlog is pure
automation, why send it to me at all? Or if you do send it to me, say
that it's just filler for _you_, not for me.

But it looks like useful information, but without human editing, it's not.

It's basically the difference between "data" and "information". I want
information, and if it's pure data that I could get from "git
shortlog" that I should just ignore, then tell me to ignore it.

         Linus

  reply	other threads:[~2017-11-21  7:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-18 18:09 [GIT PULL] platform-drivers-x86 for 4.15-1 Andy Shevchenko
2017-11-18 18:37 ` Linus Torvalds
2017-11-18 20:09   ` Linus Torvalds
2017-11-20 17:17     ` Darren Hart
2017-11-20 19:06   ` Darren Hart
2017-11-21  7:48     ` Linus Torvalds [this message]
2017-11-21 23:59       ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFx0=yO7=LaJFeDQ6MthtXYSFSAzO4gpQ6EbFwVgjRqMGA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.