git: Behaviour of the stable-rc repo

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

From that quilt tree of patches, I generate the stable-rc tree every so

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

Quoted 17 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Does this help? The stable-rc tree there is present only for those who don't like dealing with quilt, and I never use it myself, I only generate it for others who can use it for early testing.

thanks,

greg k-h

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 110 lines · Greg KH

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

Quoted 8 lines

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Ah, here's an old script that I use to set up a "blank" machine for doing kernel work:
https://github.com/gregkh/gregkh-linux/blob/master/scripts/set_it_up.sh
it might be a bit old, but you can get the idea of doing clones on local trees. You will have to change the "source" location for those 'git clone' commands, as that url doesn't work anymore, and only used to work for someone who had a kernel.org account.

thanks,

greg k-h

Quoted 7 lines · Amol Surati

Quoted 6 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

Quoted 4 lines

Quoted 2 lines

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 28 lines

Quoted 17 lines

Quoted 17 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 2 lines

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

What is "LKMP"?

And yes, you can wait for my email to do "real" testing, as that is when I am asking others to test. If you want to do testing before then, that's wonderful, but you have to be able to handle the git tree rebasing.

You can do this, by always doing a 'git pull --rebase' on the linux-stable-rc tree, but if you do that, you will loose any changes you might have had there, so don't do this on a tree you actually create patches on.

Quoted 3 lines

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Yes, my scripts just automatically add that to make it obvious that the testing kernel is not the previous release.

hope this helps,

greg k-h

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 2 lines

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

What is "LKMP"?

And yes, you can wait for my email to do "real" testing, as that is when I am asking others to test. If you want to do testing before then, that's wonderful, but you have to be able to handle the git tree rebasing.

You can do this, by always doing a 'git pull --rebase' on the linux-stable-rc tree, but if you do that, you will loose any changes you might have had there, so don't do this on a tree you actually create patches on.

Quoted 2 lines

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Yes, my scripts just automatically add that to make it obvious that the testing kernel is not the previous release.

hope this helps,

greg k-h

Quoted 140 lines · Greg KH

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 2 lines

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

What is "LKMP"?

And yes, you can wait for my email to do "real" testing, as that is when I am asking others to test. If you want to do testing before then, that's wonderful, but you have to be able to handle the git tree rebasing.

You can do this, by always doing a 'git pull --rebase' on the linux-stable-rc tree, but if you do that, you will loose any changes you might have had there, so don't do this on a tree you actually create patches on.

Quoted 2 lines

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Yes, my scripts just automatically add that to make it obvious that the testing kernel is not the previous release.

Quoted 3 lines

hope this helps,

greg k-h

Please, does a "git pull" in "linux/gregkh" merges the FETCH_HEAD of "linux/work/torvalds" (You do only "git fetch origin" here).

Quoted 141 lines · Sheriff Esseson

Quoted 140 lines · Greg KH

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 2 lines

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

What is "LKMP"?

And yes, you can wait for my email to do "real" testing, as that is when I am asking others to test. If you want to do testing before then, that's wonderful, but you have to be able to handle the git tree rebasing.

You can do this, by always doing a 'git pull --rebase' on the linux-stable-rc tree, but if you do that, you will loose any changes you might have had there, so don't do this on a tree you actually create patches on.

Quoted 2 lines

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Yes, my scripts just automatically add that to make it obvious that the testing kernel is not the previous release.

Quoted 6 lines

Quoted 3 lines

hope this helps,

greg k-h

Please, does a "git pull" in "linux/gregkh" merges the FETCH_HEAD of "linux/work/torvalds" (You do only "git fetch origin" here).

Yes, doing 'git pull' in linux/gregkh will mereg the head of torvalds into that tree. That's by design. Well, it's how I'm used to working at the least. In my linux/gregkh/ tree, which is what I use for my local development, I have a few local branches, and use the 'master' branch to track Linus's tree:

~/linux/gregkh $ git branch -v
debugfs_debugging 373b5563a69c debugfs: make error message a bit more verbose
* master d7d170a8e357 Merge tag 'tag-chrome-platform-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
wakeup d0717ad3cb44 wakeup_stats: reworked by me

Does that make sense?

Now working with a tree to do development on, is a totally different topic. There should be tutorials out there how to do this, but feel free to ask questions if you have any specific ones.

thanks,

greg k-h

Quoted 171 lines · Sheriff Esseson

Quoted 155 lines · Greg KH

Quoted 141 lines · Sheriff Esseson

Quoted 140 lines · Greg KH

Quoted 11 lines · Amol Surati

Quoted 8 lines · Greg KH

Quoted 4 lines · Amol Surati

Hi,

Since yesterday, the stable-rc branch 'linux-5.1.y' has received new commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless you really understand git :)

I don't understand git to that extent :)

Hey, you can now learn :)

Quoted 27 lines

Quoted 16 lines

Quoted 16 lines

There were 7 code-change-commits + 1 version-change-commit, which were based on the released 5.1.16. Now, when the branch has been refreshed (twice afaics) with new commits, those 8 previous commits have been assigned new identities (still based on 5.1.16).

It seems that there are 3 copies of those 8 commits. For e.g., the version-change-commit has these IDs -

57f5b343cdf9593b22d79f5261f30243c07d6515,
925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
2b5fd394355ac0b2cc9572232727cb2bce7c15a7

with 2b5... being the most recent ID (and the HEAD iinm).

Could you help me understand how these copies are created, and why?

Quoted 7 lines

Quoted 2 lines

Also, why do we want to commit the version update, if more commits are expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will be applied on top of the previous version, using a tool called quilt. That set of quilt patches can be found in the stable-queue.git tree on git.kernel.org.

Okay.

Quoted 1 line

Quoted 8 lines

Quoted 5 lines

From that quilt tree of patches, I generate the stable-rc tree every so often so that people who only use git, have an easier way to test things. The tree is constantly rebased and rebuilt every time I do a new push to it and a number of autobuilders and testing systems watch it and send me automated reports when it changes.

Okay. Some of them would be those on kernelci.org, who use 'git describe' to identify the point-in-time when reporting their results.

Yes, kernelci uses this as does others.

Quoted 11 lines

Quoted 7 lines

So I recommend ONLY using it if you just always rebase, and treat it like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable mailing list and lkml and push out a compressed patch that you can apply to the last released kernel, or you can pull from the stable-rc tree (again rebasing) if that is easier for you to test from.

Okay. Understood. The stable-rc tree that I tested yesterday was a shallow (depth 1) clone. I am assuming that rebasing would't work on it, owing to lack of necessary information.

A shallow clone of a kernel tree isn't good, you can't do much with that for a "real" git tree.

I recommend cloning Linus's tree once, and then add the linux-stable tree as a remote and pulling from that, and then taking that local tree and just using it as a base to create other local trees from for anything else.

That way you have one "real" copy of upstream, which you took the time to suck down once, and then any additions you make on top of that is always much simpler and faster. If you use the '-s' option to git when cloning the trees, you will not take up additional disk space for the .git objects.

As an example, here's how I do my work. It's a bit more complex than what you probably want to do, but you can get the idea here.

I have one "root" git tree, that is a "bare" repo:
linux/work/torvalds/
that I cloned from git.kernel.org with the --bare option. I run 'git fetch origin' on it every once in a while to keep it up to date.

I have a "local" tree that I do my work in and run my machine's kernel off of, it was created by doing:
cd linux
git clone -s linux/work/torvalds/ gregkh
and in linux/gregkh/ I have local branches and other stuff that I use for upstream development and messing around with. When I want to update it to the latest tree from Linus's tree, I just do a 'git pull' in my linux/gregkh/ directory and all is good.

For stable kernel work, I have a "real" tree that was based off of the torvalds tree, but added the upstream stable repo from. It was created by doing:
cd linux
mkdir stable
git clone -s linux/work/torvalds/ stable/linux-stable cd stable/linux-stable
git remote add stable [FULL linux-stable.git URL HERE] git fetch --all

Then, for individual specific release branches of the linux-stable tree, I create local copies of that tree. For example, to create the linux-4.19.y tree, I would do:

	cd linux/stable
	git clone -s linux-stable linux-4.19.y
	cd linux-4.19.y
	git checkout -t -b linux-4.19.y origin/linux-4.19.y

There, I have 3 different "full" source trees on my system now, but the majority of the git objects all live in linux/work/torvalds/ and after that, I only have to update tiny amounts.

Quoted 2 lines

LKMP describes both methods (stable-rc, and the compressed patch), but they need us to /wait/ for your email before attempting a test.

What is "LKMP"?

And yes, you can wait for my email to do "real" testing, as that is when I am asking others to test. If you want to do testing before then, that's wonderful, but you have to be able to handle the git tree rebasing.

You can do this, by always doing a 'git pull --rebase' on the linux-stable-rc tree, but if you do that, you will loose any changes you might have had there, so don't do this on a tree you actually create patches on.

Quoted 2 lines

The presence of '5.1.17-rc1' commit threw me off the track :) - I see now that it is not an actual -rc1 release.

Yes, my scripts just automatically add that to make it obvious that the testing kernel is not the previous release.

Quoted 6 lines

Quoted 3 lines

hope this helps,

greg k-h

Please, does a "git pull" in "linux/gregkh" merges the FETCH_HEAD of "linux/work/torvalds" (You do only "git fetch origin" here).

Yes, doing 'git pull' in linux/gregkh will mereg the head of torvalds into that tree. That's by design. Well, it's how I'm used to working at the least. In my linux/gregkh/ tree, which is what I use for my local development, I have a few local branches, and use the 'master' branch to track Linus's tree:

Quoted 6 lines

~/linux/gregkh $ git branch -v
debugfs_debugging 373b5563a69c debugfs: make error message a bit more verbose
* master d7d170a8e357 Merge tag 'tag-chrome-platform-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
wakeup d0717ad3cb44 wakeup_stats: reworked by me

Does that make sense?

Yes, it did after discovering git pull cannot run on the bare repo "linux/work/torvalds".

Quoted 5 lines

Now working with a tree to do development on, is a totally different topic. There should be tutorials out there how to do this, but feel free to ask questions if you have any specific ones.

Quoted 5 lines

Quoted 3 lines

thanks,

greg k-h

is a "git fetch origin", in effect, a "git pull origin" in a bare repo?

Nope, 'fetch' is different from 'pull'. 'pull' is a 'fetch and merge'

But pull doesn't work on a bare repo, so watch out for that.

thanks,

greg k-h