linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL]: SoundWire subsystem updates for v6.1-rc1
Date: Sat, 8 Oct 2022 18:52:46 +0530	[thread overview]
Message-ID: <Y0F5poxlesoIMa/+@matsya> (raw)
In-Reply-To: <CAHk-=wjeQyCx-FGSaBckR+HgrMPYoHY2jwRq4J4JzpOczc+3fQ@mail.gmail.com>

On 07-10-22, 16:22, Linus Torvalds wrote:
> On Fri, Oct 7, 2022 at 6:19 AM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > soundwire updates for 6.1-rc1
> >
> >  - Pierre-Louis Bossart did another round of Intel driver cleanup to prepare
> >    for future code reorg which is expected in next cycle
> >  - Richard Fitzgerald provided bus unattach notifications processing during
> >    re-enumeration along with Cadence driver updates for this.
> >  - Srinivas Kandagatla added  Qualcomm driver updates to handle device0 status
> 
> So one of the things I do for merge messages is I try to make them all
> _somewhat_ consistent.
> 
> That means that I now ended up editing all your explanations to match
> the more common pattern, where when people credit the person doing the
> work they put the name in parentheses after the explanation.

Sorry I missed that.

> Partly that is just for consistency so that our logs read more like a
> uniform body of work, but it also means that you don't need to add
> pointless filler words to the explanations ("did", "provided",
> "added").
> 
> So if you really want to mention peoples names (and it's ok, but it
> does show up in the individual commits, so I'm not convinced it's
> necessary in the merge commit overview of "what happened"), please try
> to use that model.
> 
> And no, we're not really all _that_ consistent, and there's really a
> few different merge commit patterns that we have.
> 
> Generally I try to make my editing fairly lightweight, but this was
> just _so_ different from the normal merge commit log pattern that I
> felt I needed to just edit a lot more than usual.
> 
> So a gentle query to maybe try to make them more in line with the
> other patterns in the future to avoid extra work?

Thanks for letting me know. Sorry for the trouble this caused. Will
update my template to use the edited format you have applied.

-- 
~Vinod

  reply	other threads:[~2022-10-08 13:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 13:19 [GIT PULL]: SoundWire subsystem updates for v6.1-rc1 Vinod Koul
2022-10-07 23:22 ` Linus Torvalds
2022-10-08 13:22   ` Vinod Koul [this message]
2022-10-07 23:37 ` pr-tracker-bot

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=Y0F5poxlesoIMa/+@matsya \
    --to=vkoul@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).