A patch is a collection of diffs that reside in a common file. For example, patches that contain the differences between two kernel versions are made available at www.kernel.org for updating purposes. It is then no longer necessary to download the entire source tree, thus saving time and bandwidth.
6If two files are totally different, diff creates a single large hunk that covers the whole file.
7Patches are referred to as orthogonal if they do not mutually influence each other; that is, if a patch changes only code segments that do not affect other segments.
Patches are applied with the help of the patch tool, which is not especially difficult to handle. The following statement updates the kernel sources in /home/wolfgang/linux-2.6.23 from version 2.6.23 to version 2.6.24:
patch can not only apply patches but also remove them. This is an extremely useful feature when troubleshooting because modifications can be selectively removed from the sources until a particular error no longer occurs. This at least isolates the modification that gave rise to the error.8 The -R option must be specified to "reverse" the patch. The following example reverses the kernel sources of version 2.6.24 back to version 2.6.23 by removing the preceding patch:
[email protected]> bzcat patch-2.6.24.bz2 | patch -R -p0 patch provides many other options, which are documented in detail on the patch(1) man page.
Git is a relatively novel version control system on which the Linux kernel development model is based. A large group of developers spread throughout the world are cooperating on a software product although they are not in direct personal contact. They are working not with a central repository, on which classical systems such as CVS build, but with a large number of subtrees that are synchronized with each other at intervals in order to swap changes.
The first proper version control system employed by the kernel community was BitKeeper. However, Linus Torvalds himself launched the development of an alternative tool because it was no longer possible to continue using BitKeeper due to various conflicts between BitMover (the company responsible for BitKeeper), and sections of the kernel community. The conflicts revolve around the fact that BitKeeper is not an open-source product (and is in no way free software in the GPL sense) but is sold under proprietary license. BitKeeper could be used free of charge for noncommercial purposes, but this right has been revoked by BitMover, so the kernel community had to come up with a different solution — and indeed it did.
The solution is a completely new version control system which goes by the name git. Git is designed as a content tracker — it makes a kind of database layer available to enable changes to files to be archived. Great importance is attached to the fact that necessary operations can be performed directly in the filesystem with the help of regular files — no direct database back end is needed.
Git used to have a front end by the name of cogito. It was required for early versions of git to provide the standard features of a version control system, and was easier to use than pure git. However, the former deficiencies of git have by now been resolved, so cogito is not actively being developed anymore, and it's no longer required because git provides everything directly.
qgit and gitk are graphical front ends to handle git repositories. It greatly simplifies work for those who do not use git regularly and are therefore not familiar with the numerous commands. The following sections describe the shell commands and the graphical user interface.
8Notice that git also offers possibilities to automatize the search for erroneous patches via the git-bisect tool.
Git does not rank behind BitKeeper in terms of kernel developer productivity. Because it is a very useful tool to track kernel development history, investigate errors, and carry out programming work, the focus here is on its most important characteristics. However, if you are interested in detailed information on the capabilities of git, refer to the documentation that comes with the product.
When working with git, it is very useful to create a clone of Linus Torvalds's repository as it contains the "official" kernel versions. The repository of developer version 2.6 is available at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git.It can be cloned using the following command:
[email protected]> git clone git://git.kernel.org/pub/scm/linux/kernel/git-torvalds/linux-2.6.git
Depending on the network connection, a file transfer initiated by this command takes between a few minutes and several hours (with extremely slow modems).
The following sections deal with several important commands used to track kernel development history, although these represent only part of the git functionality. Further information can be obtained by invoking the online help with git help. The help system provides an overview of available commands. A detailed description of the individual commands can be requested by entering git help command.
Continue reading here: Tracking Development History
Was this article helpful?