* git pull
@ 2017-11-14 11:05 ` Greg Kroah-Hartman
0 siblings, 0 replies; 34+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-14 11:05 UTC (permalink / raw)
To: kernelnewbies
Adding lkml and linux-doc mailing lists...
On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> Hi Greg,
>
> This is totally asking a favour, feel free to ignore. How do you format
> your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> command to get the email?
>
> I tried to do it manually and failed pretty hard (as you no doubt will
> notice on LKML).
Well, I think you got it right the third time, so nice job :)
Anyway, this actually came up at the kernel summit / maintainer meeting
a few weeks ago, in that "how do I make a good pull request to Linus" is
something we need to document.
Here's what I do, and it seems to work well, so maybe we should turn it
into the start of the documentation for how to do it.
-----------
To start with, put your changes on a branch, hopefully one named in a
semi-useful way (I use 'char-misc-next' for my char/misc driver patches
to be merged into linux-next). That is the branch you wish to tag and
have Linus pull from.
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
that will create a signed tag called 'char-misc-4.15-rc1' based on the
last commit in the char-misc-next branch, and sign it with my gpg key
KEY_ID (replace KEY_ID with your own gpg key id.)
When you run the above command, git will drop you into an editor and ask
you to describe the tag. In this case, you are describing a pull
request, so outline what is contained here, why it should be merged, and
what, if any, testing has happened to it. All of this information will
end up in the tag itself, and then in the merge commit that Linus makes,
so write it up well, as it will be in the kernel tree for forever.
An example pull request of mine might look like:
Char/Misc patches for 4.15-rc1
Here is the big char/misc patch set for the 4.15-rc1 merge
window. Contained in here is the normal set of new functions
added to all of these crazy drivers, as well as the following
brand new subsystems:
- time_travel_controller: Finally a set of drivers for
the latest time travel bus architecture that provides
i/o to the CPU before it asked for it, allowing
uninterrupted processing
- relativity_shifters: due to the affect that the
time_travel_controllers have on the overall system,
there was a need for a new set of relativity shifter
drivers to accommodate the newly formed black holes
that would threaten to suck CPUs into them. This
subsystem handles this in a way to successfully
neutralize the problems. There is a Kconfig option to
force these to be enabled when needed, so problems
should not occur.
All of these patches have been successfully tested in the latest
linux-next releases, and the original problems that it found
have all been resolved (apologies to anyone living near Canberra
for the lack of the Kconfig options in the earlier versions of
the linux-next tree creations.)
Signed-off-by: Your-name-here <your_email@domain>
The tag message format is just like a git commit id. One line at the
top for a "summary subject" and be sure to sign-off at the bottom.
Now that you have a local signed tag, you need to push it up to where it
can be retrieved by others:
git push origin char-misc-4.15-rc1
pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
The last thing to do is create the pull request message. Git handily
will do this for you with the 'git request-pull' command, but it needs a
bit of help determining what you want to pull, and what to base the pull
against (to show the correct changes to be pulled and the diffstat.)
I use the following command to generate a pull request:
git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
This is asking git to compare the difference from the
'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
(which in my case points to the last location in Linus's tree that I
diverged from, usually a -rc release) and to use the git:// protocol to
pull from. If you wish to use https://, that can be used here instead
as well (but note that some people behind firewalls will have problems
with https git pulls).
If the char-misc-4.15-rc1 tag is not present in the repo that I am
asking to be pulled from, git will complain saying it is not there, a
handy way to remember to actually push it to a public location.
The output of 'git request-pull' will contain the location of the git
tree and specific tag to pull from, and the full text description of
that tag (which is why you need to provide good information in that
tag.) It will also create a diffstat of the pull request, and a
shortlog of the individual commits that the pull request will provide.
-----------
Does all of that make sense? Anything I can explain better?
It's just 3 commands to do to create the tag, push it out, and create a
pull request text to put in an email. I have a simple script that I use
for this task to output to my console these 3 commands, based on what
kernel tree I am currently in, and what branch I am on. You can find
that script at:
https://github.com/gregkh/gregkh-linux/blob/master/work/pull_request
if you wish to laugh at my horrid perl skills :)
Hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 11:05 ` Greg Kroah-Hartman
@ 2017-11-14 12:00 ` Ulf Hansson
-1 siblings, 0 replies; 34+ messages in thread
From: Ulf Hansson @ 2017-11-14 12:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tobin C. Harding, kernelnewbies, linux-kernel, linux-doc
[...]
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
I don't add my s-o-b to signed tags for pull requests, but perhaps I should.
However, I think most maintainers don't use it, and neither does it
seems like Linus is preserving the tag when he does the pull.
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 12:00 ` Ulf Hansson
0 siblings, 0 replies; 34+ messages in thread
From: Ulf Hansson @ 2017-11-14 12:00 UTC (permalink / raw)
To: kernelnewbies
[...]
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
I don't add my s-o-b to signed tags for pull requests, but perhaps I should.
However, I think most maintainers don't use it, and neither does it
seems like Linus is preserving the tag when he does the pull.
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 12:00 ` Ulf Hansson
@ 2017-11-14 12:09 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 34+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-14 12:09 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Tobin C. Harding, kernelnewbies, linux-kernel, linux-doc
On Tue, Nov 14, 2017 at 01:00:14PM +0100, Ulf Hansson wrote:
> [...]
>
> >
> > An example pull request of mine might look like:
> > Char/Misc patches for 4.15-rc1
> >
> > Here is the big char/misc patch set for the 4.15-rc1 merge
> > window. Contained in here is the normal set of new functions
> > added to all of these crazy drivers, as well as the following
> > brand new subsystems:
> > - time_travel_controller: Finally a set of drivers for
> > the latest time travel bus architecture that provides
> > i/o to the CPU before it asked for it, allowing
> > uninterrupted processing
> > - relativity_shifters: due to the affect that the
> > time_travel_controllers have on the overall system,
> > there was a need for a new set of relativity shifter
> > drivers to accommodate the newly formed black holes
> > that would threaten to suck CPUs into them. This
> > subsystem handles this in a way to successfully
> > neutralize the problems. There is a Kconfig option to
> > force these to be enabled when needed, so problems
> > should not occur.
> >
> > All of these patches have been successfully tested in the latest
> > linux-next releases, and the original problems that it found
> > have all been resolved (apologies to anyone living near Canberra
> > for the lack of the Kconfig options in the earlier versions of
> > the linux-next tree creations.)
> >
> > Signed-off-by: Your-name-here <your_email@domain>
> >
> >
> > The tag message format is just like a git commit id. One line at the
> > top for a "summary subject" and be sure to sign-off at the bottom.
>
> I don't add my s-o-b to signed tags for pull requests, but perhaps I should.
>
> However, I think most maintainers don't use it, and neither does it
> seems like Linus is preserving the tag when he does the pull.
The text of the tag is in the merge commit, but you are right, the
signed-off-by doesn't seem to be in the merge commit, I guess Linus's
workflow removes them. I know I keep them in there if present for pull
requests that people send to me.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 12:09 ` Greg Kroah-Hartman
0 siblings, 0 replies; 34+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-14 12:09 UTC (permalink / raw)
To: kernelnewbies
On Tue, Nov 14, 2017 at 01:00:14PM +0100, Ulf Hansson wrote:
> [...]
>
> >
> > An example pull request of mine might look like:
> > Char/Misc patches for 4.15-rc1
> >
> > Here is the big char/misc patch set for the 4.15-rc1 merge
> > window. Contained in here is the normal set of new functions
> > added to all of these crazy drivers, as well as the following
> > brand new subsystems:
> > - time_travel_controller: Finally a set of drivers for
> > the latest time travel bus architecture that provides
> > i/o to the CPU before it asked for it, allowing
> > uninterrupted processing
> > - relativity_shifters: due to the affect that the
> > time_travel_controllers have on the overall system,
> > there was a need for a new set of relativity shifter
> > drivers to accommodate the newly formed black holes
> > that would threaten to suck CPUs into them. This
> > subsystem handles this in a way to successfully
> > neutralize the problems. There is a Kconfig option to
> > force these to be enabled when needed, so problems
> > should not occur.
> >
> > All of these patches have been successfully tested in the latest
> > linux-next releases, and the original problems that it found
> > have all been resolved (apologies to anyone living near Canberra
> > for the lack of the Kconfig options in the earlier versions of
> > the linux-next tree creations.)
> >
> > Signed-off-by: Your-name-here <your_email@domain>
> >
> >
> > The tag message format is just like a git commit id. One line at the
> > top for a "summary subject" and be sure to sign-off at the bottom.
>
> I don't add my s-o-b to signed tags for pull requests, but perhaps I should.
>
> However, I think most maintainers don't use it, and neither does it
> seems like Linus is preserving the tag when he does the pull.
The text of the tag is in the merge commit, but you are right, the
signed-off-by doesn't seem to be in the merge commit, I guess Linus's
workflow removes them. I know I keep them in there if present for pull
requests that people send to me.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 11:05 ` Greg Kroah-Hartman
@ 2017-11-14 18:04 ` Linus Torvalds
-1 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-14 18:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tobin C. Harding, kernelnewbies, Linux Kernel Mailing List,
open list:DOCUMENTATION
On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.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@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
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 18:04 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-14 18:04 UTC (permalink / raw)
To: kernelnewbies
On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.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 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 11:05 ` Greg Kroah-Hartman
@ 2017-11-14 21:33 ` Tobin C. Harding
-1 siblings, 0 replies; 34+ messages in thread
From: Tobin C. Harding @ 2017-11-14 21:33 UTC (permalink / raw)
To: Greg Kroah-Hartman, Linus Torvalds; +Cc: kernelnewbies, linux-kernel, linux-doc
Added Linus to To: header.
On Tue, Nov 14, 2017 at 12:05:00PM +0100, Greg Kroah-Hartman wrote:
> Adding lkml and linux-doc mailing lists...
>
> On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> > Hi Greg,
> >
> > This is totally asking a favour, feel free to ignore. How do you format
> > your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> > command to get the email?
> >
> > I tried to do it manually and failed pretty hard (as you no doubt will
> > notice on LKML).
>
> Well, I think you got it right the third time, so nice job :)
>
> Anyway, this actually came up at the kernel summit / maintainer meeting
> a few weeks ago, in that "how do I make a good pull request to Linus" is
> something we need to document.
>
> Here's what I do, and it seems to work well, so maybe we should turn it
> into the start of the documentation for how to do it.
>
> -----------
>
> To start with, put your changes on a branch, hopefully one named in a
> semi-useful way (I use 'char-misc-next' for my char/misc driver patches
> to be merged into linux-next). That is the branch you wish to tag and
> have Linus pull from.
>
> 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
>
> that will create a signed tag called 'char-misc-4.15-rc1' based on the
> last commit in the char-misc-next branch, and sign it with my gpg key
> KEY_ID (replace KEY_ID with your own gpg key id.)
>
> When you run the above command, git will drop you into an editor and ask
> you to describe the tag. In this case, you are describing a pull
> request, so outline what is contained here, why it should be merged, and
> what, if any, testing has happened to it. All of this information will
> end up in the tag itself, and then in the merge commit that Linus makes,
> so write it up well, as it will be in the kernel tree for forever.
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
>
> Now that you have a local signed tag, you need to push it up to where it
> can be retrieved by others:
> git push origin char-misc-4.15-rc1
> pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
>
> The last thing to do is create the pull request message. Git handily
> will do this for you with the 'git request-pull' command, but it needs a
> bit of help determining what you want to pull, and what to base the pull
> against (to show the correct changes to be pulled and the diffstat.)
>
> I use the following command to generate a pull request:
> git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
>
> This is asking git to compare the difference from the
> 'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
> (which in my case points to the last location in Linus's tree that I
> diverged from, usually a -rc release) and to use the git:// protocol to
> pull from. If you wish to use https://, that can be used here instead
> as well (but note that some people behind firewalls will have problems
> with https git pulls).
Linus do you care what protocol? I'm patching Documentation and since
the point is creating pull requests for you 'some people' don't matter.
thanks,
Tobin.
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 21:33 ` Tobin C. Harding
0 siblings, 0 replies; 34+ messages in thread
From: Tobin C. Harding @ 2017-11-14 21:33 UTC (permalink / raw)
To: kernelnewbies
Added Linus to To: header.
On Tue, Nov 14, 2017 at 12:05:00PM +0100, Greg Kroah-Hartman wrote:
> Adding lkml and linux-doc mailing lists...
>
> On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> > Hi Greg,
> >
> > This is totally asking a favour, feel free to ignore. How do you format
> > your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> > command to get the email?
> >
> > I tried to do it manually and failed pretty hard (as you no doubt will
> > notice on LKML).
>
> Well, I think you got it right the third time, so nice job :)
>
> Anyway, this actually came up at the kernel summit / maintainer meeting
> a few weeks ago, in that "how do I make a good pull request to Linus" is
> something we need to document.
>
> Here's what I do, and it seems to work well, so maybe we should turn it
> into the start of the documentation for how to do it.
>
> -----------
>
> To start with, put your changes on a branch, hopefully one named in a
> semi-useful way (I use 'char-misc-next' for my char/misc driver patches
> to be merged into linux-next). That is the branch you wish to tag and
> have Linus pull from.
>
> 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
>
> that will create a signed tag called 'char-misc-4.15-rc1' based on the
> last commit in the char-misc-next branch, and sign it with my gpg key
> KEY_ID (replace KEY_ID with your own gpg key id.)
>
> When you run the above command, git will drop you into an editor and ask
> you to describe the tag. In this case, you are describing a pull
> request, so outline what is contained here, why it should be merged, and
> what, if any, testing has happened to it. All of this information will
> end up in the tag itself, and then in the merge commit that Linus makes,
> so write it up well, as it will be in the kernel tree for forever.
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
>
> Now that you have a local signed tag, you need to push it up to where it
> can be retrieved by others:
> git push origin char-misc-4.15-rc1
> pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
>
> The last thing to do is create the pull request message. Git handily
> will do this for you with the 'git request-pull' command, but it needs a
> bit of help determining what you want to pull, and what to base the pull
> against (to show the correct changes to be pulled and the diffstat.)
>
> I use the following command to generate a pull request:
> git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
>
> This is asking git to compare the difference from the
> 'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
> (which in my case points to the last location in Linus's tree that I
> diverged from, usually a -rc release) and to use the git:// protocol to
> pull from. If you wish to use https://, that can be used here instead
> as well (but note that some people behind firewalls will have problems
> with https git pulls).
Linus do you care what protocol? I'm patching Documentation and since
the point is creating pull requests for you 'some people' don't matter.
thanks,
Tobin.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 21:33 ` Tobin C. Harding
@ 2017-11-14 21:46 ` Linus Torvalds
-1 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-14 21:46 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Greg Kroah-Hartman, kernelnewbies, Linux Kernel Mailing List,
open list:DOCUMENTATION
On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>
> Linus do you care what protocol? I'm patching Documentation and since
> the point is creating pull requests for you 'some people' don't matter.
I actually tend to prefer the regular git:// protocol and signed tags.
It's true that https should have the proper certificate and perhaps
help with DNS spoofing, but I'm not convinced that git won't just
accept self-signed random certs, and I basically don't think we should
trust that.
In contrast, using ssh I would actually trust, but it's not convenient
and involves people sending things that aren't necessarily publicly
available.
So instead, I prefer just using git:// and not trying to fool people
into thinking the protocol is secure - the security should come from
the signed tag.
And then people can do this:
[url "ssh://git@gitolite.kernel.org"]
insteadOf = https://git.kernel.org
insteadOf = http://git.kernel.org
insteadOf = git://git.kernel.org
which makes git.kernel.org addresses use ssh, and avoid the whole
possible DNS spoofing problem.
That said, I actually would prefer even kernel.org repositories to
just send pull requests with signed tags, despite the protocol itself
being secure for that (and only that).
Other hosts I will simply not trust without it because I can't do the above.
Side note: there's an unrelated advantage of using "git://" over
"https://". It means that people who do automation see that it's a git
repo. It also means, for example, that people that highlight https://
URL's and perhaps use them for spam marking hopefully don't do that
with git:// format.
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 21:46 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-14 21:46 UTC (permalink / raw)
To: kernelnewbies
On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>
> Linus do you care what protocol? I'm patching Documentation and since
> the point is creating pull requests for you 'some people' don't matter.
I actually tend to prefer the regular git:// protocol and signed tags.
It's true that https should have the proper certificate and perhaps
help with DNS spoofing, but I'm not convinced that git won't just
accept self-signed random certs, and I basically don't think we should
trust that.
In contrast, using ssh I would actually trust, but it's not convenient
and involves people sending things that aren't necessarily publicly
available.
So instead, I prefer just using git:// and not trying to fool people
into thinking the protocol is secure - the security should come from
the signed tag.
And then people can do this:
[url "ssh://git at gitolite.kernel.org"]
insteadOf = https://git.kernel.org
insteadOf = http://git.kernel.org
insteadOf = git://git.kernel.org
which makes git.kernel.org addresses use ssh, and avoid the whole
possible DNS spoofing problem.
That said, I actually would prefer even kernel.org repositories to
just send pull requests with signed tags, despite the protocol itself
being secure for that (and only that).
Other hosts I will simply not trust without it because I can't do the above.
Side note: there's an unrelated advantage of using "git://" over
"https://". It means that people who do automation see that it's a git
repo. It also means, for example, that people that highlight https://
URL's and perhaps use them for spam marking hopefully don't do that
with git:// format.
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 21:46 ` Linus Torvalds
@ 2017-11-15 10:51 ` Michael Ellerman
-1 siblings, 0 replies; 34+ messages in thread
From: Michael Ellerman @ 2017-11-15 10:51 UTC (permalink / raw)
To: Linus Torvalds, Tobin C. Harding
Cc: Greg Kroah-Hartman, kernelnewbies, Linux Kernel Mailing List,
open list:DOCUMENTATION
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>>
>> Linus do you care what protocol? I'm patching Documentation and since
>> the point is creating pull requests for you 'some people' don't matter.
>
> I actually tend to prefer the regular git:// protocol and signed tags.
>
> It's true that https should have the proper certificate and perhaps
> help with DNS spoofing, but I'm not convinced that git won't just
> accept self-signed random certs, and I basically don't think we should
> trust that.
git does not accept self-signed certs by default, at least in recent
versions.
Though you can do a trust-on-first-use type thing, by downloading the
cert and telling git where to find it.
So https does provide additional security vs git:// IMHO. There is some
verification of the server and your data is encrypted on the wire.
It's not like it would be trivial to MITM a git fetch to insert a
malicious Makefile change, but it's also not *hard*.
> In contrast, using ssh I would actually trust, but it's not convenient
> and involves people sending things that aren't necessarily publicly
> available.
>
> So instead, I prefer just using git:// and not trying to fool people
> into thinking the protocol is secure - the security should come from
> the signed tag.
That's true, but only when you're pulling a signed tag, which for most
people is not the common case.
...
> That said, I actually would prefer even kernel.org repositories to
> just send pull requests with signed tags, despite the protocol itself
> being secure for that (and only that).
Which you mention here.
cheers
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-15 10:51 ` Michael Ellerman
0 siblings, 0 replies; 34+ messages in thread
From: Michael Ellerman @ 2017-11-15 10:51 UTC (permalink / raw)
To: kernelnewbies
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding <me@tobin.cc> wrote:
>>
>> Linus do you care what protocol? I'm patching Documentation and since
>> the point is creating pull requests for you 'some people' don't matter.
>
> I actually tend to prefer the regular git:// protocol and signed tags.
>
> It's true that https should have the proper certificate and perhaps
> help with DNS spoofing, but I'm not convinced that git won't just
> accept self-signed random certs, and I basically don't think we should
> trust that.
git does not accept self-signed certs by default, at least in recent
versions.
Though you can do a trust-on-first-use type thing, by downloading the
cert and telling git where to find it.
So https does provide additional security vs git:// IMHO. There is some
verification of the server and your data is encrypted on the wire.
It's not like it would be trivial to MITM a git fetch to insert a
malicious Makefile change, but it's also not *hard*.
> In contrast, using ssh I would actually trust, but it's not convenient
> and involves people sending things that aren't necessarily publicly
> available.
>
> So instead, I prefer just using git:// and not trying to fool people
> into thinking the protocol is secure - the security should come from
> the signed tag.
That's true, but only when you're pulling a signed tag, which for most
people is not the common case.
...
> That said, I actually would prefer even kernel.org repositories to
> just send pull requests with signed tags, despite the protocol itself
> being secure for that (and only that).
Which you mention here.
cheers
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 21:46 ` Linus Torvalds
@ 2017-11-16 20:36 ` Linus Torvalds
-1 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-16 20:36 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Greg Kroah-Hartman, kernelnewbies, Linux Kernel Mailing List,
open list:DOCUMENTATION
On Tue, Nov 14, 2017 at 1:46 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And then people can do this:
>
> [url "ssh://git@gitolite.kernel.org"]
> insteadOf = https://git.kernel.org
> insteadOf = http://git.kernel.org
> insteadOf = git://git.kernel.org
>
> which makes git.kernel.org addresses use ssh, and avoid the whole
> possible DNS spoofing problem.
So credit goes for Konstantin for pointing that out, and I actually
used it this merge window.
A few notes for other people who end up doing this:
(a) ssh is slower, and the gitolite machine is not as reachable.
(b) it affects your merge commit message.
As to (a), yes it's noticeable, but the extra couple of seconds isn't
really that big of a deal. Depending on exactly where you are, though,
you might end up wanting to use https:// to the public servers
instead.
But (b) actually ends up being annoying, because I don't like my merge
commits to contain references to repositories that aren't actually
available unless you have a kernel.org account.
I tried to edit things up by hand, but honestly, that just meant that
I forgot about 50% of the time. Do a
git log --author=Torvalds --grep=ssh://gitolite
to see my shameful lack of actually fixing up the end result.
Happily, once you realize that you have the attention span of a
slightly retarded chipmunk, and that you keep on forgetting to fix
things up, you hopefully also go "I'm a moron, but I can compensate
for that automatically".
Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
#!/bin/sh
sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
and make it executable, and git will do that commit message editing for you.
Tadaa! Now you don't look like quite the tool that I did.
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-16 20:36 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-16 20:36 UTC (permalink / raw)
To: kernelnewbies
On Tue, Nov 14, 2017 at 1:46 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And then people can do this:
>
> [url "ssh://git at gitolite.kernel.org"]
> insteadOf = https://git.kernel.org
> insteadOf = http://git.kernel.org
> insteadOf = git://git.kernel.org
>
> which makes git.kernel.org addresses use ssh, and avoid the whole
> possible DNS spoofing problem.
So credit goes for Konstantin for pointing that out, and I actually
used it this merge window.
A few notes for other people who end up doing this:
(a) ssh is slower, and the gitolite machine is not as reachable.
(b) it affects your merge commit message.
As to (a), yes it's noticeable, but the extra couple of seconds isn't
really that big of a deal. Depending on exactly where you are, though,
you might end up wanting to use https:// to the public servers
instead.
But (b) actually ends up being annoying, because I don't like my merge
commits to contain references to repositories that aren't actually
available unless you have a kernel.org account.
I tried to edit things up by hand, but honestly, that just meant that
I forgot about 50% of the time. Do a
git log --author=Torvalds --grep=ssh://gitolite
to see my shameful lack of actually fixing up the end result.
Happily, once you realize that you have the attention span of a
slightly retarded chipmunk, and that you keep on forgetting to fix
things up, you hopefully also go "I'm a moron, but I can compensate
for that automatically".
Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
#!/bin/sh
sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
and make it executable, and git will do that commit message editing for you.
Tadaa! Now you don't look like quite the tool that I did.
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-16 20:36 ` Linus Torvalds
(?)
@ 2017-11-20 5:37 ` Junio C Hamano
2017-11-20 6:04 ` Linus Torvalds
-1 siblings, 1 reply; 34+ messages in thread
From: Junio C Hamano @ 2017-11-20 5:37 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
Linus Torvalds <torvalds@linux-foundation.org> writes:
> A few notes for other people who end up doing this:
[this meaning use of insteadOf to redirect public URLs to
ssh://git@gitolite URL]
> (a) ssh is slower, and the gitolite machine is not as reachable.
>
> (b) it affects your merge commit message.
>
> As to (a), yes it's noticeable, but the extra couple of seconds isn't
> really that big of a deal. Depending on exactly where you are, though,
> you might end up wanting to use https:// to the public servers
> instead.
>
> But (b) actually ends up being annoying, because I don't like my merge
> commits to contain references to repositories that aren't actually
> available unless you have a kernel.org account.
> ...
> Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
>
> #!/bin/sh
> sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
>
> and make it executable, and git will do that commit message editing for you.
This should work with any recent versions of Git (1.7.4.2 and
upwards), but it still is a workaround. Should we mark it as a
feature request in the Git land to record the URL you typed as-is in
the builtin/fetch.c::store_updated_refs() function, instead of the
one that was rewritten by the insteadOf mechanism?
It would probably need an update to "struct remote" to have new
fields, to teach remote.c::alias_all_urls() not to overwrite the
url[] (and pushurl[] merely for symmetry) fields, to add a field to
"struct transport" and teach transport.c::transport_get() to record
the original URL in it so that builtin/fetch.c::fetch_refs() can
give it to store_updated_refs() instead of the rewritten one.
Many tiny changes in a rather deep codepath, but feels fairly a safe
change that is isolated and straightforward.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-20 5:37 ` Junio C Hamano
@ 2017-11-20 6:04 ` Linus Torvalds
0 siblings, 0 replies; 34+ messages in thread
From: Linus Torvalds @ 2017-11-20 6:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
On Sun, Nov 19, 2017 at 7:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains
>>
>> #!/bin/sh
>> sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
>>
>> and make it executable, and git will do that commit message editing for you.
>
> This should work with any recent versions of Git (1.7.4.2 and
> upwards), but it still is a workaround. Should we mark it as a
> feature request in the Git land to record the URL you typed as-is in
> the builtin/fetch.c::store_updated_refs() function, instead of the
> one that was rewritten by the insteadOf mechanism?
The main problem with the prepare-commit-msg thing is actually that is
such a nasty hack, and it can change other things than just the remote
name. Maybe "gitolite" might be mentioned in the shortlog of the
merge, and then the sed script comes and edits that part too.
It is really not a huge issue simply because those things don't really
happen in real life, but it's the main thing about that
prepare-commit-msg hook that makes me go "eww, what an ugly hack".
But it's an ugly hack that just happens to work pretty well in practice.
And yes, I looked at alternatives. In fact, I looked at a couple of
other approaches:
- the one you mention, namely to remember the original url, and use
that instead
- the one I'd actually prefer, which is to generalize the whole
"insteadOf" to work in more situations.
Why would I prefer that second one? It turns out that the "original"
isn't actually necessarily what I'd want either. Several people send
me pointers to "https://git.kernel.org/" and I prefer rewriting them
to git:// just to be consistent. And now that people have started
doing the "insteadOf", their pull requests end up containing that
"git@gitolite" version of the URL, so again, I'd actually like to
rewrite the url _anyway_ in the commit message.
For example, for the kernel, the git.kernel.org address is very
common, but it also has a very common path prefix, so almost all pull
messages for the kernel have that
"git://git.kernel.org/pub/scm/linux/kernel/git/"
part in common, and I have occasioally felt that it's not adding a lot
of value particularly as it shows up in shortlogs and gitk. I could
change my own rules for the first line (instead of the "Merge tag xyz
from git://..." maybe I should just have my human-legible version),
but I have also considered just rewriting the url to something that
shortens that very common thing.
So maybe
Merge tag 'sound-4.10-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
could be instead
Merge tag 'sound-4.10-rc4' of git://kernel.org/../tiwai/sound
which would keep the _important_ part, and shorten the boilerplate
part away. But that kind of "insteadOf" would only be for the message,
since the end result isn't actually a "real" URL at all, it's
literally a rewritten shorthand.
Again, I can do all of this with the sed script. But again, it's kind
of wrong to do it on the whole message, when it's really only the url
that it should affect.
So it would potentially be nice to just have a generic "rewrite the
url" model, where you can do it for remote fetches, but you could also
do it for just the commit message, or you could do it for doing pushes
(we do have that "pushinsteadof" already - exactly because you might
want to pull and push from different versions, with the push having to
use ssh).
But, as you say:
> It would probably need an update to "struct remote" to have new
> fields, to teach remote.c::alias_all_urls() not to overwrite the
> url[] (and pushurl[] merely for symmetry) fields, to add a field to
> "struct transport" and teach transport.c::transport_get() to record
> the original URL in it so that builtin/fetch.c::fetch_refs() can
> give it to store_updated_refs() instead of the rewritten one.
Yes, the existing "insteadOf" is actually hidden surprisingly deep in
the remote code, and it's very non-obvious. That works ok for the pull
and push case, but really not for just the message rewriting case
(which doesn't happen as part of the pull, but as part of the "git
merge" that then takes the FETCH_HEAD or MERGE_HEAD that contains the
url, and parses that).
Anyway, it's not a big deal. The sed script works. It's a bit hacky,
but it does the job.
I might have wished for a different model, but it's almost certainly
not worth the effort unless somebody really gets fired up about this
and decides they really want to do it.
Linus
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: git pull
2017-11-14 11:05 ` Greg Kroah-Hartman
@ 2017-11-14 21:42 ` Tobin C. Harding
-1 siblings, 0 replies; 34+ messages in thread
From: Tobin C. Harding @ 2017-11-14 21:42 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: kernelnewbies, linux-kernel, linux-doc
On Tue, Nov 14, 2017 at 12:05:00PM +0100, Greg Kroah-Hartman wrote:
> Adding lkml and linux-doc mailing lists...
>
> On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> > Hi Greg,
> >
> > This is totally asking a favour, feel free to ignore. How do you format
> > your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> > command to get the email?
> >
> > I tried to do it manually and failed pretty hard (as you no doubt will
> > notice on LKML).
>
> Well, I think you got it right the third time, so nice job :)
Lucky. Three strikes and your out isn't it?
> Anyway, this actually came up at the kernel summit / maintainer meeting
> a few weeks ago, in that "how do I make a good pull request to Linus" is
> something we need to document.
>
> Here's what I do, and it seems to work well, so maybe we should turn it
> into the start of the documentation for how to do it.
Patch to come.
> -----------
>
> To start with, put your changes on a branch, hopefully one named in a
> semi-useful way (I use 'char-misc-next' for my char/misc driver patches
> to be merged into linux-next). That is the branch you wish to tag and
> have Linus pull from.
>
> 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
>
> that will create a signed tag called 'char-misc-4.15-rc1' based on the
> last commit in the char-misc-next branch, and sign it with my gpg key
> KEY_ID (replace KEY_ID with your own gpg key id.)
>
> When you run the above command, git will drop you into an editor and ask
> you to describe the tag. In this case, you are describing a pull
> request, so outline what is contained here, why it should be merged, and
> what, if any, testing has happened to it. All of this information will
> end up in the tag itself, and then in the merge commit that Linus makes,
> so write it up well, as it will be in the kernel tree for forever.
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
>
> Now that you have a local signed tag, you need to push it up to where it
> can be retrieved by others:
> git push origin char-misc-4.15-rc1
> pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
>
> The last thing to do is create the pull request message. Git handily
> will do this for you with the 'git request-pull' command, but it needs a
> bit of help determining what you want to pull, and what to base the pull
> against (to show the correct changes to be pulled and the diffstat.)
>
> I use the following command to generate a pull request:
> git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
>
> This is asking git to compare the difference from the
> 'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
> (which in my case points to the last location in Linus's tree that I
> diverged from, usually a -rc release) and to use the git:// protocol to
> pull from. If you wish to use https://, that can be used here instead
> as well (but note that some people behind firewalls will have problems
> with https git pulls).
>
> If the char-misc-4.15-rc1 tag is not present in the repo that I am
> asking to be pulled from, git will complain saying it is not there, a
> handy way to remember to actually push it to a public location.
>
> The output of 'git request-pull' will contain the location of the git
> tree and specific tag to pull from, and the full text description of
> that tag (which is why you need to provide good information in that
> tag.) It will also create a diffstat of the pull request, and a
> shortlog of the individual commits that the pull request will provide.
>
> -----------
>
> Does all of that make sense? Anything I can explain better?
Awesome explanation. +1 for the new subsystems ;)
thanks,
Tobin.
^ permalink raw reply [flat|nested] 34+ messages in thread
* git pull
@ 2017-11-14 21:42 ` Tobin C. Harding
0 siblings, 0 replies; 34+ messages in thread
From: Tobin C. Harding @ 2017-11-14 21:42 UTC (permalink / raw)
To: kernelnewbies
On Tue, Nov 14, 2017 at 12:05:00PM +0100, Greg Kroah-Hartman wrote:
> Adding lkml and linux-doc mailing lists...
>
> On Tue, Nov 14, 2017 at 10:11:55AM +1100, Tobin C. Harding wrote:
> > Hi Greg,
> >
> > This is totally asking a favour, feel free to ignore. How do you format
> > your [GIT PULL] emails to Linus? Do you create a tag and then run a git
> > command to get the email?
> >
> > I tried to do it manually and failed pretty hard (as you no doubt will
> > notice on LKML).
>
> Well, I think you got it right the third time, so nice job :)
Lucky. Three strikes and your out isn't it?
> Anyway, this actually came up at the kernel summit / maintainer meeting
> a few weeks ago, in that "how do I make a good pull request to Linus" is
> something we need to document.
>
> Here's what I do, and it seems to work well, so maybe we should turn it
> into the start of the documentation for how to do it.
Patch to come.
> -----------
>
> To start with, put your changes on a branch, hopefully one named in a
> semi-useful way (I use 'char-misc-next' for my char/misc driver patches
> to be merged into linux-next). That is the branch you wish to tag and
> have Linus pull from.
>
> 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
>
> that will create a signed tag called 'char-misc-4.15-rc1' based on the
> last commit in the char-misc-next branch, and sign it with my gpg key
> KEY_ID (replace KEY_ID with your own gpg key id.)
>
> When you run the above command, git will drop you into an editor and ask
> you to describe the tag. In this case, you are describing a pull
> request, so outline what is contained here, why it should be merged, and
> what, if any, testing has happened to it. All of this information will
> end up in the tag itself, and then in the merge commit that Linus makes,
> so write it up well, as it will be in the kernel tree for forever.
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well as the following
> brand new subsystems:
> - time_travel_controller: Finally a set of drivers for
> the latest time travel bus architecture that provides
> i/o to the CPU before it asked for it, allowing
> uninterrupted processing
> - relativity_shifters: due to the affect that the
> time_travel_controllers have on the overall system,
> there was a need for a new set of relativity shifter
> drivers to accommodate the newly formed black holes
> that would threaten to suck CPUs into them. This
> subsystem handles this in a way to successfully
> neutralize the problems. There is a Kconfig option to
> force these to be enabled when needed, so problems
> should not occur.
>
> All of these patches have been successfully tested in the latest
> linux-next releases, and the original problems that it found
> have all been resolved (apologies to anyone living near Canberra
> for the lack of the Kconfig options in the earlier versions of
> the linux-next tree creations.)
>
> Signed-off-by: Your-name-here <your_email@domain>
>
>
> The tag message format is just like a git commit id. One line at the
> top for a "summary subject" and be sure to sign-off at the bottom.
>
> Now that you have a local signed tag, you need to push it up to where it
> can be retrieved by others:
> git push origin char-misc-4.15-rc1
> pushes the char-misc-4.15-rc1 tag to where the 'origin' repo is located.
>
> The last thing to do is create the pull request message. Git handily
> will do this for you with the 'git request-pull' command, but it needs a
> bit of help determining what you want to pull, and what to base the pull
> against (to show the correct changes to be pulled and the diffstat.)
>
> I use the following command to generate a pull request:
> git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
>
> This is asking git to compare the difference from the
> 'char-misc-4.15-rc1' tag location, to the head of the 'master' branch
> (which in my case points to the last location in Linus's tree that I
> diverged from, usually a -rc release) and to use the git:// protocol to
> pull from. If you wish to use https://, that can be used here instead
> as well (but note that some people behind firewalls will have problems
> with https git pulls).
>
> If the char-misc-4.15-rc1 tag is not present in the repo that I am
> asking to be pulled from, git will complain saying it is not there, a
> handy way to remember to actually push it to a public location.
>
> The output of 'git request-pull' will contain the location of the git
> tree and specific tag to pull from, and the full text description of
> that tag (which is why you need to provide good information in that
> tag.) It will also create a diffstat of the pull request, and a
> shortlog of the individual commits that the pull request will provide.
>
> -----------
>
> Does all of that make sense? Anything I can explain better?
Awesome explanation. +1 for the new subsystems ;)
thanks,
Tobin.
^ permalink raw reply [flat|nested] 34+ messages in thread