From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756265AbdKNSFG (ORCPT ); Tue, 14 Nov 2017 13:05:06 -0500 Received: from mail-it0-f48.google.com ([209.85.214.48]:55496 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755189AbdKNSEo (ORCPT ); Tue, 14 Nov 2017 13:04:44 -0500 X-Google-Smtp-Source: AGs4zMb3HbWpK8/NWJTW5EskG1IpO1T59/HRUm4PoRMWdc57ndtr1H3K7JA4g1dd9J5bYS3uWj+HIcb6VHK05xgKhP8= MIME-Version: 1.0 In-Reply-To: <20171114110500.GA21175@kroah.com> References: <20171113231155.GA26779@eros> <20171114110500.GA21175@kroah.com> From: Linus Torvalds Date: Tue, 14 Nov 2017 10:04:42 -0800 X-Google-Sender-Auth: IQ8uKe2O8elAOAT1rwCpnBpYxNw Message-ID: Subject: Re: git pull To: Greg Kroah-Hartman Cc: "Tobin C. Harding" , kernelnewbies@kernelnewbies.org, Linux Kernel Mailing List , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman 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@linux-foundation.org signingkey = torvalds@linux-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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: torvalds@linux-foundation.org (Linus Torvalds) Date: Tue, 14 Nov 2017 10:04:42 -0800 Subject: git pull In-Reply-To: <20171114110500.GA21175@kroah.com> References: <20171113231155.GA26779@eros> <20171114110500.GA21175@kroah.com> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman 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 at i7 ~]$ head -4 .gitconfig [user] name = Linus Torvalds email = torvalds at linux-foundation.org signingkey = torvalds at linux-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