linux-kernel - Re: [PATCH] docs: process: Add base-commit trailer usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191107200508.j4qm7ic42pijkr2a@chatter.i7.local>
Date:   Thu, 7 Nov 2019 15:05:08 -0500
From:   Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To:     Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs: process: Add base-commit trailer usage

On Thu, Nov 07, 2019 at 01:00:52PM -0700, Jonathan Corbet wrote:
>On Wed, 30 Oct 2019 10:00:50 -0400
>Konstantin Ryabitsev <konstantin@...uxfoundation.org> wrote:
>
>> One of the recurring complaints from both maintainers and CI system
>> operators is that performing git-am on received patches is difficult
>> without knowing the parent object in the git history on which the
>> patches are based. Without this information, there is a high likelihood
>> that git-am will fail due to conflicts, which is particularly
>> frustrating to CI operators.
>>
>> Git versions starting with v2.9.0 are able to automatically include
>> base-commit information using the --base flag of git-format-patch.
>> Document this usage in process/submitting-patches, and add the rationale
>> for its inclusion, plus instructions for those not using git on where
>> the "base-commit:" trailer should go.
>>
>> Signed-off-by: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
>
>I really wish we could find a way to make submitting-patches.rst shorter
>rather than longer - it's a lot for a first-time submitter to work
>through.  But this is useful information, so I've applied it.

I think that's the eventual goal, and I'm happy to take a stab at making 
this page shorter. The easiest would be to rewrite that page so that it 
only includes git-specific instructions. I think at this point in time 
we can safely say that anyone who need guidance on submitting patches 
would be already using git -- anyone who doesn't use git for that 
process doesn't really need this doc anyway.

I'll work on an RFC patch to slim this doc down.

-K