"Is there a write up of what you consider the 'proper' git workflow?" Theodore Ts'o asked Linux creator Linus Torvalds, "why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer." He went on to differentiate between 'grunts' who write the code and 'managers' who primarily collect other people's code, "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." Linus compared his own patch management style and productivity from over six years ago before he started using BK and git, to his current style using git:

"You can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the 'let other people help you', because otherwise you _will_ burn out. It's not a matter of 'if', but of 'when'. [...] And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges. [...] I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago."

"This time around, we have 60+% of the changes in drivers, notably drives/video and drivers/media, with some infiniband, networking and usb lovin' to fill things out," began Linux creator Linus Torvalds, announcing the 2.6.26-rc3 kernel. "The rest is (as usual) mostly arch updates," he continued, "this time mostly mips, m68k and uml." Linus noticed that Linux kernel development has been managed with git now as long as it was managed with BitKeeper, a little over three years for both tools. He explained, "the most striking difference has nothing to do with git or BK (the switch-over timing was just the reason I decided to take a look), but with the fact that we're not just continuing to develop, but we're developing faster and with more people," adding:

"So during the three years 2002->2005, we had 63,428 commits, attributed to 1,560 different authors (caveat: misspellings etc will mean that some people get counted more than once). During the last three years, we've had 96,885 attributed to 4,068 distinct authors (with the same caveat, obviously).

"I didn't do a lot of per-commit statistics yet, but from the little I've done it also seems like we've gotten increasingly better at doing small commits (which is probably one of the reasons we have a larger number of them, but also why we have more authors - small commits is how people get into doing kernel development)."

"The latest feature release GIT 1.5.5 is available at the usual places," began Git maintainer Junio Hamano, adding "we kept this cycle just slightly over two months, as the previous 1.5.4 cycle was painfully tooooo long."

Git is a distributed version control system that was originally written by Linus Torvalds in April of 2005. It was written to be only a temporary replacement for BitKeeper, which Linus had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with git-gui 0.10.1; bunch of portability improvement patches coming from an effort to port to Solaris has been applied; 'git fetch' over the native git protocol used to make a connection to find out the set of current remote refs and another to actually download the pack data. We now use only one connection for these tasks; 'git commit' does not run lstat(2) more than necessary anymore; bash completion script (in contrib) are aware of more commands and options; a catch-all 'color.ui' configuration variable can be used to enable coloring of all color-capable commands, instead of individual ones such as 'color.status' and 'color.branch'; bash completion's prompt helper function can talk about operation in-progress (e.g. merge, rebase, etc.); 'git help' can use different backends to show manual pages and this can be configured using 'man.viewer' configuration; 'git gui' learned an auto-spell checking; 'git checkout' and 'git remote' are rewritten in C; two conflict hunks that are separated by a very short span of common lines are now coalesced into one larger hunk, to make the result easier to read."

"The latest feature release GIT 1.5.4 is available at the usual places," began Git maintainer Junio Hamano. He continued, "it has been an unusually long cycle. 5 months since the last feature release 1.5.3 was really a bit too long. But I hope it was worth waiting for. Thanks everybody for working hard to improve it." He noted that there were 165 contributers resulting in 684 changed files, included 70,435 insertions and 28,984 deletions.

The Git distributed version control system was originally written by Linus Torvalds in April of 2005 to temporarily replace BitKeeper, which he had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git a few months later, in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with much improved gitk, with i18n; comes with git-gui 0.9.2 with i18n; progress displays from many commands are a lot nicer to the eye; rename detection of diff family while detecting exact matches has been greatly optimized; 'git diff' sometimes did not quote paths with funny characters properly; various Perforce importer updates; 'git clean' has been rewritten in C; 'git push' learned --dry-run option to show what would happen if a push is run; 'cvs' is recognized as a synonym for 'git cvsserver', so that CVS users can be switched to git just by changing their login shell; 'git add -i' UI has been colorized; 'git commit' has been rewritten in C; 'git bisect' learned 'skip' action to mark untestable commits; 'git svn' wasted way too much disk to record revision mappings between svn and git, a new representation that is much more compact for this information has been introduced to correct this; in addition there are quite a few internal clean-ups."

In a recent lkml thread, the idea of getting the entire Linux kernel history into a git repository was discussed. Linus Torvalds noted, "I actually tried to get something like this together back in the BK days and early in the SCO saga. It was pretty painful to try to find all the historic trees and patches - they're all in different format, and some of them are unreliable." He added, "I've been thinking about trying to re-create some really old history into git, but it's still a lot of work.. And obviously not very useful, just interesting from an archaeological standpoint." Much information on early Linux kernels is gathered at oldlinux.org, and Linus already has the full 2.5.0 to 2.6.12-rc2 history imported from BitKeeper available in git. Linus went on to talk about why git is better suited than BK was for building a complete kernel history:

"The good news is that git would be a lot more natural to the process of trying to create a history, because you could basically import random trees, and tag them as just independent trees, and then re-create the history after-the-fact by trying to stitch them all together. And if you find a new tree, you'd just re-stitch it - something that was very hard to do with BK (and BK generally wouldn't help you with keeping multiple independent trees around, and wouldn't generally accept the notion of re-doing the histories and keeping various versions of the histories around)."

Petr Baudis announced the creation of a homepage for git, the directory content manager used to manage the Linux kernel. Git was originally written by Linus Torvalds in early April of 2005 [story], and is now maintained by Junio Hamano [story]. Other online resources available for the tool include a tutorial that walks through the process of setting up and using git, a man page, and the gitweb interface providing easy browsing of the many kernel trees managed by git. The new webpage explains:

"GIT falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every GIT working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server."

The git directory content manager was born in early April of 2005 [story], less than a week after the announcement that BitKeeper would no longer be available free of charge to kernel developers [story]. The tool was originally written by Linux creator Linus Torvalds, and rapidly evolved with the help of an active developer community which Linus repeatedly noted he hoped would eventually take over [story]. A scant two months after development on the tool began, the 2.6.12 kernel was released, managed by git [story].

Now, Linus has announced that Junio Hamano is the new git maintainer. "I always said I didn't really want to maintain it in the long run," Linus explained, "and maybe some of you thought I was just saying that, especially as the weeks dragged out to over three months, but hey, that's just because this thing ended up being a bit bigger and more professional than I originally even envisioned." He went on to note that Junio was the obvious choice, and that this change means he will be able to return his full focus to the Linux Kernel mailing list.

Junio thanked those involved, described his development methods, and discussed the upcoming 1.0 release. Regarding 1.0, he suggested that all features are in, and that he is primarily looking for bugfixes and documentation updates. Following the announcement, Ryan Anderson posted an updated "Git 1.0 Synopis", a brief overview of the tool and its features. His document begins, "Git, sometimes called 'global information tracker', is a 'directory content manager'. Git has been designed to handle absolutely massive projects with speed and efficiency, and the release of the 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it does this task well."

Linus Torvalds began working on an interim solution called "git" in the absence of BitKeeper [story]. A README included with the source describes it as, "a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently." The documentation goes on to describe two abstractions used by the tool, an "object database", and a "current directory cache". Objects in the object database are referred to by the SHA1 hash of their zlib compressed contents. The various supported object types include, "blobs" which are simply binary blobs of data with no added verification, "trees" which are lists of objects sorted by name, and "changesets" which provide a historical view of an object describing "how we got there, and why". The current directory cache is a binary file "which contains an efficient representation of a virtual directory content at some random time."

During the discussion regarding git and its rapid evolution, Linus explained, "in many ways you can just see git as a filesystem - it's content- addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a _filesystem_ person (hey, kernels is what I do), and I actually have absolutely _zero_ interest in creating a traditional SCM system." As for actual usage, Linus noted, "I think we can make the workflow look like bk, ie pretty much like "git pull" and "git push". And for well-behaved stuff (ie minimal changes to the same files on both sides) it will even be fast. I think." Read on for much of the resulting discussion which provides a fuller understanding of how the evolving tool will work.

Linus Torvalds offered an explanation to the lkml of the recent decision to switch away from using BitKeeper to manage the Linux kernel [story]. He began, "as a number of people are already aware (and in some cases have been aware over the last several weeks), we've been trying to work out a conflict over BK usage over the last month or two (and it feels like longer ;). That hasn't been working out, and as a result, the kernel team is looking at alternatives." He continued on to thank Larry and BitMover for their efforts in trying to make things work. He added, "NOTE! BitKeeper isn't going away per se. Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;)"

Citing the fact that his three years of BitKeeper usage have helped him to improve how he works on the kernel, he added, "so I just wanted to say that I'm personally very happy with BK, and with Larry. It didn't work out, but it sure as hell made a big difference to kernel development. And we'll work out the temporary problem of having to figure out a set of tools to allow us to continue to do the things that BK allowed us to do." As for what tool was likely to replace BitKeeper, Linus offered, "don't bother telling me about subversion. If you must, start reading up on 'monotone'. That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;)"

BitKeeper was first utilized by a Linux project in December of 1999, when it was employed by the Linux PowerPC project. Then in February of 2002, Linux creator Linus Torvalds decided that BitKeeper was "the best tool for the job" and started using it to manage the mainline kernel, an event that received much attention in the free and open source communities [story], and beyond. BitMover, the company behind BitKeeper, was founded by its current CEO, Larry McVoy [interview], who originally conceived of BitKeeper as a tool to keep Linus from getting burnt out by the growing task of managing the Linux Kernel. Since Linus began using the tool three years ago, the pace of Linux kernel development has doubled [story].

There are two definitions for the word "free" that are commonly used to describe software. The first is "Free as in Freedom", and the other is "Free as in Free Beer". BitKeeper was made available freely under the latter definition, allowing free and open source software developers to use the tool without having to pay any money. It was provided under the agreement that anyone actively using the free tool would not develop a competing product at the same time. In other words, the aim was to provide a tool that could be freely used, but not freely cloned. At the same time, a more advanced version of BitKeeper has been sold commercially, and both products remain the intellectual property of BitMover.

A vocal group has long protested Linus' use of BitKeeper, considering Linux the free and open source flagship product. GNU Project founder Richard Stallman [interview] is among the protestors, harshly criticizing Linus' decision to use a non-free (as in freedom) tool [story]. However, most acknowledge that no free tool currently exists that is as powerful as BitKeeper, offering the ability to perform truly distributed development. Attempts to reverse engineer some of BitKeeper's features have lead to repeated cautions by BitMover. Most recently two such reverse engineering attempts have contributed to BitMover's decision to end the development and availability of the free BitKeeper product.

Three years after Linux creator Linus Torvalds began using BitKeeper to manage the Linux kernel source tree, debates have continued to spring up on the Linux kernel mailing list [story]. A BitKeeper press release from nearly a year ago claims that the move has resulted in doubling the pace of Linux kernel development, a claim examined in a later two part interview on NewsForge from last May, including comments from Linus and Larry McVoy [interview]. In spite of this significant boost in productivity, there remains a group who vehemently oppose Linus' choice to use BitKeeper.

In a recent thread, Larry noted that the version of BitKeeper in use by Linux kernel developers uses an unsigned short to count changesets, and that in about 100 days the number of changesets in the Linux kernel source tree will grow too large to fit in this variable. A new version of BK will soon be released to allow developers to continue to work even after this 64 thousand changeset boundary is reached. While explaining this, Larry also noted that there was a plan to update the BK license to provide a more precise definition of what is and what is not allowed. Specifically, as is, the license requires that you agree to not work on another SCM product if you use or have used the free BK product. Larry explains, "we've had some people who have indicated that they believed that if they used BK they were agreeing that they would never work on another SCM system. We can see how it is possible that people would interpret the license that way but that wasn't our intent. What we would like to do is change the language to say that if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. But after that you would be able to hack on anything that you wanted."

Larry went on to note that the reason for this clause is to prevent people from using the free BK product, then to stop using it to work on a competing product, then to go back and use the free BK product again gathering more ideas, then to stop using it to further work on the competing product, and so on. For anyone unwilling to use BK due to its licensing, there are numerous alternative methods for obtaining up-to-date snapshots of the Linux kernel, and Linus continues to accept plain text patch files from non-BK users.

Linux creator Linus Torvalds made the decision a year and a half ago on February 5, 2002 to use BitKeeper to manage the distributed development of the Linux kernel source tree. Over the course of the next year, this led to many lengthy flame wars on the lkml [story], though in recent months things have been mostly quiet on this front... until recently, when a couple of threads threatened to return to the fiery depths.

Fortunately, the threads have also led to some interesting comments by Linus. For example, he explains his incentive for improving the Linux kernel:

"I'm ok with other people using NT. When it's better for them, that's their choice. I work hard to make sure that the Linux kernel is technically superior, and if I feel it isn't I want to fix it. Because I do _not_ want people using Linux for religious reasons. I want people to use Linux because it is _better_ for them, [or] because they truly believe that they can make it so (or at least have fun trying)."

No matter which side of the debate you're on, the following emails are usually interesting, often rather humorous, and always brashly to the point. Toward the end of the thread, Linus sarcastically refers to earlier more topical threads, pleading, "Now can we get back to complaining about the scheduler behaviour and xmms? Please?"

Pavel Machek recently announced a new project on the lkml called BitBucket. This project aims to provide read only access (at least for now) to a BitKeeper repository.

There have been numerous flame wars and discussions on the lkml regarding the use of BitKeeper in Linux kernel development [story] [story] [story] [story] [story]. During one of these earlier wars, Linux creator Linus Torvalds explained his position, "Would I prefer to use a tool that didn't have any restrictions on it for kernel maintenance? Yes. But since no such tool exists, and since I'm personally not very interested in writing one, _and_ since I don't have any hangups about using the right tool for the job, I use BitKeeper."

BitKeeper is a source management tool provided under any of three licenses, one of which - the BKL - can make BitKeeper available for free (as in free beer). Tom Gall posted a question to the lkml when he noticed a clause in the BKL intended to prevent an individual or organization from using BitKeeper under this free license if they or their employer develops, produces, sells or resells a competing product. Yet another lengthy discussion followed.

Some contributers to this discussion seem to overlook two simple facts: First, that BitKeeper is also available under commercial (non-free) licensing, and second, that BitKeeper is and always has been primarily a commercial product (hence the sarcastic title of this article). Granted, the wording of any legal verbiage is open to interpretation, but as BitMover founder Larry McVoy [interview] has publicly interpreted this clause as "if you make or sell a competing product, you don't get to use ours for free", there seems little risk it can be used to attain other ends. In any case, for now Linus and many other Linux kernel developers have chosen to utilize BitKeeper in their efforts, and it is still possible to view the latest code (within 3 hours) without using BitKeeper via archives such as this one set up by Rik van Riel [interview].

That said, there are many interesting points raised during this discussion. Read on for the full thread...

Update (October 6 @ 9am EST): Hourly snapshots of the latest 2.5 development tree can also be found here on ftp.kernel.org. Linus sarcastically summarized complaints, "Big boo-hoo, bitkeeper is evil, and Linus doesn't manually do any more what BK plus a few scripts does better for us automatically."