All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [GIT PULL] per signal_struct coredumps
Date: Fri, 05 Nov 2021 11:37:55 -0500	[thread overview]
Message-ID: <871r3uy2vw.fsf@disp2133> (raw)
In-Reply-To: <CAHk-=wivLcb3ELGSf=fM0u=PxP5m1=jRrVXDOr0+QJZRZggaHg@mail.gmail.com> (Linus Torvalds's message of "Wed, 3 Nov 2021 12:34:44 -0700")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, Nov 3, 2021 at 12:07 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> Please pull the per_signal_struct_coredumps-for-v5.16 branch
>
> I've pulled it, but I'm not convinced about that odd extra merge
> commit that contains the commentary.
>
> That's what signed tags are for, and they have that explanation that
> then makes it into the merge - plus they have the crypto signature to
> show it all comes from you.
>
> So that would have been the much better model than a fake extra merge.
>
> But at least that extra merge did have explanations, so at least it
> doesn't trigger me on _that_ level.

I have been creating those when I place a patchset with an interesting
cover letter in a branch.  Now with the entire branch being just that
patchset, it doesn't make a lot of sense (except as somewhere to store
that cover letter so I don't loose it).  At other times when there are
multiple sets of changes on a single branch I think it makes more sense.

Am I missing a better way to preserve the cover letter for the
changes when multiple sets of changes land in a single branch?

Eric

  reply	other threads:[~2021-11-05 16:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 19:07 [GIT PULL] per signal_struct coredumps Eric W. Biederman
2021-11-03 19:32 ` pr-tracker-bot
2021-11-03 19:34 ` Linus Torvalds
2021-11-05 16:37   ` Eric W. Biederman [this message]
2021-11-13 19:14     ` Linus Torvalds
2021-11-14  6:32       ` Junio C Hamano
2021-11-14  9:36         ` Ævar Arnfjörð Bjarmason
2021-11-14 17:16         ` Eric W. Biederman
2021-11-16  6:49           ` Junio C Hamano
2021-11-16  8:29           ` Junio C Hamano
2021-11-16 15:14             ` Eric W. Biederman
2021-11-18  9:29             ` Junio C Hamano

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=871r3uy2vw.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.