git pull

git pull

[matteo brutti]

Hi,
i'm learning about git and soon have a question.
My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
local i thought that when i committ, i'll found the files on repo
changed, it was not so! I learn i have to use git pull, but i didn't
understand why.
I made some tries, put my repo in /home/user/myrepo cloned in
/home/user/myclones changed files and committed and the changes was in
the repo without any need of pulling, and i have permission to write
to /dev/sda6, so why have i to pull changes?

Thanks.


Matteo

Re: git pull

[Nicolas Sebrecht]

The 17/05/10, matteo brutti wrote:

> Hi,

Hi,

> i'm learning about git and soon have a question.
> My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
> local i thought that when i committ, i'll found the files on repo
> changed, it was not so! I learn i have to use git pull, but i didn't
> understand why.

"/dev/sda" is the physical device and "/dev/sda6" a physical partition
of the hard drive "sda".

Inside a partition, we may find (usually after the installation process
of the system) a filesytem. The filesytem contains the files we can
access to when mounted to the virtual filesytem (begining at "/").

While using user application which works on usual files (like git does),
we don't care about the underlying local hard drive device ("/dev/sda"
here).

You can safely forget all the "/dev/<something>" things here.

> I made some tries, put my repo in /home/user/myrepo cloned in
> /home/user/myclones changed files and committed and the changes was in
> the repo without any need of pulling, and i have permission to write
> to /dev/sda6, so why have i to pull changes?

With the above in mind, could you please try to rephrase your problem
(and maybe provide a basic use case with the commands to reproduce it) ?

-- 
Nicolas Sebrecht

Re: git pull

[hasen j]

On 17 May 2010 15:51, matteo brutti <webmbackslash@gmail.com> wrote:
> Hi,
> i'm learning about git and soon have a question.
> My repo is in /dev/sda6 and my home is in /dev/sda4, as are both in
> local i thought that when i committ, i'll found the files on repo
> changed, it was not so! I learn i have to use git pull, but i didn't
> understand why.
> I made some tries, put my repo in /home/user/myrepo cloned in
> /home/user/myclones changed files and committed and the changes was in
> the repo without any need of pulling, and i have permission to write
> to /dev/sda6, so why have i to pull changes?
>
> Thanks.
>
>
> Matteo

If you clone repoA into repoB, then you commit some new changes to
repoA, you won't see the same changes in repoB unless you pull them
from repoA.

I don't think it matters whether or not they are in the same partition or not.

As far as I understand, if you clone within the same partition, the
object database might be hard-linked. This won't affect what files you
have checked out though. It would just mean that you won't need to
"fetch", because the objects are already there.

Re: git pull

[Linus Torvalds]

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

Re: git pull

[Junio C Hamano]

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.

Re: git pull

[Linus Torvalds]

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

git pull

[Linus Torvalds]

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

Re: git pull

[Michael Ellerman]

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

git pull

[Michael Ellerman]

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

Re: git pull

[Linus Torvalds]

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

git pull

[Linus Torvalds]

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

Re: git pull

[Tobin C. Harding]

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.

git pull

[Tobin C. Harding]

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.

Re: git pull

[Tobin C. Harding]

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.

git pull

[Tobin C. Harding]

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.

Re: git pull

[Linus Torvalds]

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

git pull

[Linus Torvalds]

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

Re: git pull

[Greg Kroah-Hartman]

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

git pull

[Greg Kroah-Hartman]

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

Re: git pull

[Ulf Hansson]

[...]

>
> 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

git pull

[Ulf Hansson]

[...]

>
> 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

Re: git pull

[Greg Kroah-Hartman]

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

git pull

[Greg Kroah-Hartman]

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

git pull

[Tobin C. Harding]

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).

thanks,
Tobin.

Re: GIT pull

[cvalusek]

Looks like it's the virus scan. I had this e-mail that I accidentally sent to
Michael directly instead of the list:

I will see if I can build a script that reproduces the issue we are seeing. 

We are starting to speculate about what is going on now. Maybe our virus
scan is causing some git operation to fail in the middle of the merge.

The "terrible state" is a half-way applied merge.

--
View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7460163.html
Sent from the git mailing list archive at Nabble.com.

Re: GIT pull

[Johannes Sixt]

Am 12.04.2012 16:47, schrieb cvalusek:
> My team has had a lot of trouble with GIT lately because of aborted pull
> commands.
> 
> If a user has local modifications not on the index and does a pull, I have
> seen git attempt to start applying the merge to master and abort. The whole
> checkout is then left in a terrible state that is nearly unrecoverable. In
> the past, I thought GIT would run some sort of check to identify these
> problems before it attempts the merge.
> 
> Even with a clean state (nothing to commit), I have seen the same thing
> randomly happen at least once.

As others pointed out, this should not happen. That leaves one
possibility: You are on Windows, and you very likely have one or more of

- a virus scanner
- an IDE

running. It can happen that one of these programs happen to look at a
file at the same moment when git is trying to remove or rename the file.
This fails because on Windows a file that is open cannot be removed or
renamed. In this situation, the merge/checkout is aborted in the middle
and leaves a mess behind.

There's not a lot that can be done about it. I thought we have some
counter measures in our compatibility layer (e.g., retry the removal if
the first attempt fails due to permissions), but I have seen this happen
nevertheless. I haven't tried tracking it down because it happens so
rarely for me, and it didn't hurt *too* much so far.

-- Hannes

Re: GIT pull

[Michael Witten]

On Thu, Apr 12, 2012 at 15:03, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> cvalusek <clintv2@gmail.com> writes:
>
>> If a user has local modifications not on the index and does a pull, I have
>> seen git attempt to start applying the merge to master and abort. The whole
>> checkout is then left in a terrible state that is nearly
>> unrecoverable.
>
> What do you mean by "terrible state"? What does "git status" say?
>
>> In the past, I thought GIT would run some sort of check to identify
>> these problems before it attempts the merge.
>
> Git does check uncommited changes before merging. It allows the merge if
> the changes touch different files (i.e. if the merge is guaranteed not
> to touch the same files as the one for which you have uncommited
> changes).

Also, if there *are* conflicts, then you should get an error that
looks like the following:

  error: Your local changes to the following files would be
  overwritten by merge:
  	some-file.txt
  Please, commit your changes or stash them before you can merge.
  Aborting

Sincerely,
Michael Witten

Re: GIT pull

[Matthieu Moy]

cvalusek <clintv2@gmail.com> writes:

> If a user has local modifications not on the index and does a pull, I have
> seen git attempt to start applying the merge to master and abort. The whole
> checkout is then left in a terrible state that is nearly
> unrecoverable.

What do you mean by "terrible state"? What does "git status" say?

> In the past, I thought GIT would run some sort of check to identify
> these problems before it attempts the merge.

Git does check uncommited changes before merging. It allows the merge if
the changes touch different files (i.e. if the merge is guaranteed not
to touch the same files as the one for which you have uncommited
changes).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

GIT pull

[cvalusek]

My apologies if this isn't the appropriate place to post this. We are using
the windows port msysgit so I understand if I need to post over there first.

I have also posted this on stackoverflow. Here is a link to the question
there:

http://stackoverflow.com/questions/10110401/why-doesnt-git-clean-up-when-aborting-a-merge-triggered-from-pulling-in-changes

My team has had a lot of trouble with GIT lately because of aborted pull
commands.

If a user has local modifications not on the index and does a pull, I have
seen git attempt to start applying the merge to master and abort. The whole
checkout is then left in a terrible state that is nearly unrecoverable. In
the past, I thought GIT would run some sort of check to identify these
problems before it attempts the merge.

Even with a clean state (nothing to commit), I have seen the same thing
randomly happen at least once. I understand that without rebasing, you may
be forced to resolve merge conflicts when you pull, but this is not what is
happening though.

We are using gitolite. I am mainly using command line and have yet to run
into these issues. The rest of the team is using the git-gui or in 1 case
TortoiseGit.

git-gui version 0.13.GITGUI
git version 1.7.8.msysgit.0
Tcl/Tk version 8.5.1
TortoiseGit 1.7.6.0

We are not working with branches as much as we could, but feel like this
should be working.
Why does GIT allow you to try to pull when it is going to train-wreck?
Why does GIT not abort cleanly?

--
View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7459655.html
Sent from the git mailing list archive at Nabble.com.

Re: git pull

[Khem Raj]

On Tue, Jan 19, 2010 at 10:37 AM, Paul Wilson
<paul@paulwilsonconsulting.com> wrote:
> I am having the same problem as Robin. Any suggestions?

read the wiki
http://wiki.openembedded.net/index.php/GitPhraseBook#Upgrading_your_data_.28lurking.29

>
> Paul
>
>
> On 19/01/2010 1:09 AM, robin wrote:
>>
>> One more input, When i use
>> git pull
>> Already up-to-date.
>>
>> and when i use
>> git pull --rebase
>> recipes/ti/ti-xdctools-native_3.15.01.59.bb: needs update
>> recipes/ti/ti-xdctools.inc: needs update
>> refusing to pull with rebase: your working tree is not up-to-date
>>
>> what is the correct command ?
>>
>> Robin
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: git pull

[Bjørn Forsman]

Hi Robin,

2010/1/19 robin <robinpv@iwavesystems.com>:
> One more input, When i use
> git pull
> Already up-to-date.
>
> and when i use
> git pull --rebase
> recipes/ti/ti-xdctools-native_3.15.01.59.bb: needs update
> recipes/ti/ti-xdctools.inc: needs update
> refusing to pull with rebase: your working tree is not up-to-date
>
> what is the correct command ?

You have a dirty working directory. Either 'stash' your changes away or
'commit' them to get to a clean state. (Or you can blow away the changes with
'git checkout .'.) Then do git pull/rebase.

Best regards,
Bjørn Forsman

Re: git pull

[Paul Wilson]

I am having the same problem as Robin. Any suggestions?

Paul


On 19/01/2010 1:09 AM, robin wrote:
> One more input, When i use
> git pull
> Already up-to-date.
>
> and when i use
> git pull --rebase
> recipes/ti/ti-xdctools-native_3.15.01.59.bb: needs update
> recipes/ti/ti-xdctools.inc: needs update
> refusing to pull with rebase: your working tree is not up-to-date
>
> what is the correct command ?
>
> Robin
>    
>

Re: git pull

[robin]

One more input, When i use
git pull
Already up-to-date.

and when i use
git pull --rebase
recipes/ti/ti-xdctools-native_3.15.01.59.bb: needs update
recipes/ti/ti-xdctools.inc: needs update
refusing to pull with rebase: your working tree is not up-to-date

what is the correct command ?

Robin

On Tue, 2010-01-19 at 13:31 +0530, robin wrote:

> I am using the Openembedded for the beagleboard.
> I had setup using below steps
> 
> export OETREE="${HOME}/OE" 
> mkdir -p ${OETREE} && cd ${OETREE} 
> git clone git://git.openembedded.org/openembedded.git openembedded 
> cd openembedded git checkout origin/stable/2009 -b stable/2009
> cd ${OETREE}/openembedded 
> git pull
> 
> and then
> bitbake beagleboard-demo-image
> 
> Now i wanted to update recipes folder.
> git pull --rebase
> 
> It showed files which needs update. So i gave below command
> git pull 
> 
> But the recipes/ti folder is not updated with latest files,
> which command needs to be used to update recipes directory ?
> 
> Robin
> 
> ------------------------------------------------------------------------------- 
> DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
> intended recipient (s) only. It may contain proprietary material, confidential
> information and/or be subject to the legal privilege of iWave Systems
> Technologies Private Limited. If you have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly prohibited from retaining,
> using, copying, alerting or disclosing the content of this message. Thank you
> for your co-operation. 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel



------------------------------------------------------------------------------- 
DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
intended recipient (s) only. It may contain proprietary material, confidential
information and/or be subject to the legal privilege of iWave Systems
Technologies Private Limited. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from retaining,
using, copying, alerting or disclosing the content of this message. Thank you
for your co-operation. 
------------------------------------------------------------------------------

git pull

[robin]

I am using the Openembedded for the beagleboard.
I had setup using below steps

export OETREE="${HOME}/OE" 
mkdir -p ${OETREE} && cd ${OETREE} 
git clone git://git.openembedded.org/openembedded.git openembedded 
cd openembedded git checkout origin/stable/2009 -b stable/2009
cd ${OETREE}/openembedded 
git pull

and then
bitbake beagleboard-demo-image

Now i wanted to update recipes folder.
git pull --rebase

It showed files which needs update. So i gave below command
git pull 

But the recipes/ti folder is not updated with latest files,
which command needs to be used to update recipes directory ?

Robin

------------------------------------------------------------------------------- 
DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
intended recipient (s) only. It may contain proprietary material, confidential
information and/or be subject to the legal privilege of iWave Systems
Technologies Private Limited. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from retaining,
using, copying, alerting or disclosing the content of this message. Thank you
for your co-operation. 
------------------------------------------------------------------------------