Linux kernel “historical” git repository with full history
I think many developers like to investigate sources with the help of git gui blame . As explained in the commit for Linux-2.6.12-rc2 (also mirrored at Github), it needs to have special historical Linux repository for this purpose.
Linux-2.6.12-rc2
Initial git repository build. I’m not bothering with the full history, even though we have it. We can create a separate “historical” git archive of that later if we want to, and in the meantime it’s about 3.2GB when imported into git — space that would just make the early git days unnecessarily complicated, when we don’t have a lot of good infrastructure for it.
I have looked at a lot of the prepared historical repositories but I didn’t find one containing changes going back to version zero, so I gave up and am asking this question here.
4 Answers 4
I have a repository with a clone of the following remotes:
And the following grafts ( info/grafts ):
With these grafts, I have an unbroken view of the kernel history since 0.01. The first graft glues together the very first release in Linus’ repository with the corresponding release of tglx/history.git . The second graft glues together tglx/history.git and davej/history.git .
There are a few older versions missing, and the older versions have release granularity instead of patch granularity, but this is the best setup I know of.
Edit: Dave Jones pointed me to http://www.archive.org/details/git-history-of-linux, which seems to be exactly what you want.
Here is a review of available 2018 options with a focus on tag availability and date correctness.
https://archive.org/download/git-history-of-linux/full-history-linux.git.tar
Developed by Dave Jones, and made available on archive.org .
- Covers early versions to 2010.
- 244,464 commits
- Just 184 tags, covering versions in 2.6. The tags that should have been created for all versions seem to be missing.
- Early commits have realistic dates, but incorrect times ( 11:00:00 199X -0600 ).
- Some dates seem to be incorrect. For example, both 2.1.110 and 2.1.111 are dated Wed May 20 11:00:00 1998 -0600 , although the latest file in the 2.1.111 snapshot is dated 1998-07-25 09:17 .
- The creation process is documented on GitHub and seems very thorough.
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/
Created by Thomas Gleixner.
- Covers 2.4.0 to 2.6.12-rc2.
- Contains 170 tags covering 2.5.X and 2.6.X.
- 63,428 commits
- Dates are correct.
- Contains patches converted into commits.
https://github.com/mpe/linux-fullhistory
Created by Michael Ellerman, derived from work by Yoann Padioleau, based on historical trees reconstructed by Dave Jones and Thomas Gleixner, and Linus’ mainline tree.
- Covers full history
- Provides only 558 tags, mostly starting at 2.0.0.
- 790,471 commits
- Same issues with dates as in Dave Jones’s repo.
- Uses replace objects instead of grafts.
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Owned by the Linux history team.
- Covers early versions to 2.6.33-rc5.
- 1710 tags, starting with 0.10, covering most early versions.
- 244,774 commits
- Most historic versions are incorrectly dated Fri Nov 23 15:09:04 2007 -0500 .
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
Modern Linux development.
- Covers 2.6.12-rc2 (2005) until today
- 569 tags
- 777,419 commits (August 2018)
- Proper commits
Why does the Linux kernel repository have only one branch? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago .
I’m a Linux beginner, so forgive me if this is the most obvious question you’ve ever heard.
2 Answers 2
Mainline kernel
First of all: don’t use that github link (it’s just a mirror). The actual repositories are located at kernel.org. You probably want to use Linus Torvalds’ tree, which is torvalds/linux.git.
It’s called mainline kernel, which means this tree is the one where actual development of next kernel version is happening. Although it has only master branch, you can checkout to any kernel version using tags. This command will show you all version tags:
You can checkout to desired tag like that:
There is no need in a bunch of branches for mainline kernel, as development process in this tree never stops, and once new version is released, there won’t be any back-porting to that version (inside mainline tree). So Linus sticks to tags (instead of branches) in this case.
Stable kernel
There is also linux-stable tree. «Stable» means that after release, some bug fixes would be back-ported to it. In this tree you should look for branches (rather than tags):
You can see branches like:
where y suffix is just a placeholder for a bugfix version (because naming scheme is linux-4.x.y ). Whenever you see y suffix — it’s a stable kernel branch. Some of those branches are LTS kernels (read this for details).
In this case branches are needed because developers have to backport some bug fixes into released versions. So just tags are not enough here.
Next kernel
It also should be mentioned that there is linux-next tree. Here is the description from kernel process documentation:
Before updates from subsystem trees are merged into the mainline 4.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis:
This way, the -next kernel gives a summary outlook onto what will be expected to go into the mainline kernel at the next merge period. Adventurous testers are very welcome to runtime-test the -next kernel.
Maintainer trees
Back to the trees. Actually there are many of them, they are called maintainers trees. You can see all of them here.
You need to understand merging policy: only Linus can actually merge code to the mainline tree. You can see a lot of merge commits from him in git log. So if you want your patch to be applied to mainline kernel, you need to send it to kernel mailing lists for review first. See Documentation/SubmittingPatches. Once your patch is reviewed and acknowledged by corresponding subsystem maintainer, he will apply it to his own tree. From there this patch will be merged to mainline kernel during next merge window. Linux kernel development model is described here.
Ubuntu Wiki
KernelGitGuide
Git is the source code management tool used by the Linux kernel developer community. Ubuntu has adopted this tool for our own Linux kernel source code so that we can interact better with the community and the other kernel developers.
Installing GIT
To use git you must have the git package installed on your system, which you can install like this:
Obtaining the kernel sources for an Ubuntu release using git
The source for each release is maintained in its own git repository on Launchpad.
The git repository is listed in the Vcs-Git: header in the source package and is of the following form:
For example, the standard Cosmic kernel is available at:
There is a tree for each of the currently supported releases as well as any open development and upcoming releases:
ubuntu-kernel/ubuntu/+source/linux/+git/eoan
ubuntu-kernel/ubuntu/+source/linux/+git/disco
ubuntu-kernel/ubuntu/+source/linux/+git/bionic
ubuntu-kernel/ubuntu/+source/linux/+git/xenial
ubuntu-kernel/ubuntu/+source/linux/+git/trusty
ubuntu-kernel/ubuntu/+source/linux/+git/precise
The distro kernel is always on the master branch in these repositories. Each release also has a master-next branch containing the commits that will go onto the master branch and become the next release for that release.
A number of releases also have other source packages which represent other related but divergent kernels for other purposes. For example, there is a specialised AWS kernel available in the linux-aws source package. (Previously these sorts of things were done in Topic Branches and some older kernels and projects still use them.)
If you cannot use the git protocol (perhaps because of a firewall), you can use the slower http protocol. For example:
Obtaining a copy
To obtain a local copy you can simply git clone the repository for the release you are interested. The git command is part of the git package.
For example to obtain the Bionic tree:
This will download several hundred megabytes of data. If you plan on working on more than one kernel release you can save space and time by downloading the upstream kernel tree. Note that once these two trees are tied together you cannot remove the virgin Linus tree without damage to the Ubuntu tree:
In each case you will end up with a new directory ubuntu- containing the source and the full history which can be manipulated using the git command from within each directory.
By default you will have the latest version of the kernel tree, the master tree. You can switch to any previously released kernel version using the release tags. To obtain a full list of the tagged versions in the release as below:
To look at the 2.6.27-7.13 version you can simply checkout a new branch pointing to that version:
You may then manipulate the release — for example, by adding new commits.
Maintaining local changes
During development, the kernel git repository is being constantly rebased against Linus’ tree. IOW, Ubuntu specific changes are not being merged, but rather popped off, the tree updated to mainline, and then the Ubuntu specific changes reapplied; they are rebased. There are two ways to track the kernel git tree, depending on whether you have local changes or not:
No Local Changes
Preserve Local Changes
Pushing changes to the main repo
Since the main repo is not publicly writable, the primary means for sending patches to the kernel team is using git format-patch. The output from this command can then be sent to the kernel-team mailing list.
Alternatively, if you have a publicly available git repository for which changes can be pulled from, you can use git request-pull to generate an email message to send to the kernel-team mailing list.
Using Commit templates
In debian/commit-templates/ in the source tree there are several templates that should be used when committing changes that you expect to be integrated with the Ubuntu kernel repo. The commit templates contain comments for how to fill out the required information. Also note that all commits must have a Signed-off-by line (the «-s» option to git commit). A typical git commit command will look like:
Note that the -e (edit) option must follow the -F option, else git will not let you edit the commit-template before committing. The primary one you will use is the patch template. It is commented heavily, so should be self explanatory. Some templates do not require editing such as the bumpabi and updateconfigs templates. An example commit log will look like this:
The first line is critical and should summarise the change. The prefix for the line defines the type of the commit (see below). The last line should contain your sign-off for the patch and any acks it has received. The remainder of the text should concisely describe the change.
a kernel source modification which is specific to Ubuntu
a change to the kernel configuration
any other change to the debian packaging for the kernel
upstream kernel patches