linux-kernel - Re: git pull

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyCu3_Qx2oBLO8229kSDqaM5SfNhB_L1ironkmiBF8-gA@mail.gmail.com>
Date:   Tue, 14 Nov 2017 10:04:42 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Tobin C. Harding" <me@...in.cc>, kernelnewbies@...nelnewbies.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: git pull

On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> Name the tag with something useful that you can understand if you run
> across it in a few weeks, and something that will be "unique".
> Continuing the example of my char-misc tree, for the patches to be sent
> to Linus for the 4.15-rc1 merge window, I would name the tag
> 'char-misc-4.15-rc1':
>         git tag -u KEY_ID -s char-misc-4.15-rc1 char-misc-next

Side note: since you _usually_ would use the same key for the same
project, just set it once with

    git config user.signingkey "keyname"

and if you use the same key for everything, just add "--global".

Or just edit your .git/config or ~/.gitconfig file by hand, it's
designed to be human-readable and writable, and not some garbage like
XML:

   [torvalds@i7 ~]$ head -4 .gitconfig
   [user]
        name = Linus Torvalds
        email = torvalds@...ux-foundation.org
        signingkey = torvalds@...ux-foundation.org

it's not really all that complicated ;)

Then you don't  need that "-u KEY_ID" when you sign things.

Anyway, at least to me, the important part is the *message*. I want to
understand what I'm pulling, and why I should pull it. I also want to
use that message as the message for the merge, so it should not just
make sense to me, but make sense as a historical record too.

Note that if there is something odd about the pull request, that
should very much be in the explanation. If you're touching files that
you don't maintain, explain _why_. I will see it in the diffstat
anyway, and if you didn't mention it, I'll just be extra suspicious.
And when you send me new stuff after the merge window (or even
bug-fixes, but ones that look scary), explain not just what they do
and why they do it, but explain the _timing_. What happened that this
didn't go through the merge window..

I will take both what you write in the email pull request _and_ in the
signed tag, so depending on your workflow, you can either describe
your work in the signed tag (which will also automatically make it
into the pull request email), or you can make the signed tag just a
placeholder with nothing interesting in it, and describe the work
later when you actually send me the pull request.

And yes, I will edit the message. Partly because I tend to do just
trivial formatting (the whole indentation and quoting etc), but partly
because part of the message may make sense for me at pull time
(describing the conflicts and your personal issues for sending it
right now), but may not make sense in the context of a merge commit
message, so I will try to make it all make sense. I will also fix any
speeling mistaeks and bad grammar I notice, particularly for
non-native speakers (but also for native ones ;^). But I may miss
some, or even add some.

               Linus