"As promised, this cycle was short and the release is with only relatively small impact changes," said Git maintainer Junio Hamano, announcing the release of Git v1.5.6. He noted that both gitk and git-gui have been updated. To improve portability, when running "git init", git now autodetects whether or not a filesystem is case insensitive, and updates a new configuration variable accordingly. Dependencies on the 'cpio' and 'curl' binaries have also been removed. Among the changes improving performance, the "git clone" command has been rewritten in C. Other changes include:

"'git bisect help' gives longer and more helpful usage information; 'git branch' (and 'git checkout -b') can be told to set up branch..rebase automatically, so that later you can say 'git pull' and magically cause 'git pull --rebase' to happen; 'git cherry-pick' and 'git revert' can add a sign-off; 'git commit' mentions the author identity when you are committing somebody else's changes; 'git log' and friends learned the '--graph' option to show the ancestry graph at the left margin of the output; 'git send-email' now can send out messages outside a git repository; 'git svn' learned --add-author-from option to propagate the authorship by munging the commit log message; new object creation and looking up in 'git svn; has been optimized."

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

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

"This lovely dark 4am is as good an occasion as any to offer to you the 5th issue of the msysGit Herald, the not-quite-biweekly news letter to keep you informed about msysGit, the effort to bring one of the most powerful Source Code Management systems to the poor souls stuck with Windows," began Johannes Schindelin on the git mailing list. He noted that the project was finally concentrating on getting git to work on Windows, having finally gotten the installer working. The Git on MSys project home page notes,

"Unfortunately, Git on Windows is only officially supported using Cygwin. However, there is a fork (hopefully to be merged with 'official' git real soon now) which enables you to compile git using MinGW/MSys. It is a little bit tricky to get ahold of everything needed (MSys, iconv, Tcl/Tk, gcc, make, zlib, regex, etc.), so this project tries to provide a single .zip (actually, a 7-Zip packed installer) which you can unpack, and by double-clicking on msys.bat everything is set. You can start right away to hack on your favourite Source Code Management tool."

"As most folks are probably now well aware, Junio has been offline for about 11 days and may still be offline for a little while more," Shawn Pearce explained regarding git maintainer Junio Hamano's recent absence from Git development. He noted, "I'm not going to get into the specific details as it is Junio's business and not mine. But I can say that my thoughts and prayers to $DEITY are with him and his family at this time, and I don't expect him to be rushing back to git work tomorrow. However I'm quite certain that Junio will return when he can."

Shawn continued on explaining, "I've decided to step up and try to fill Junio's shoes. To that end I am publishing a maint, master, next (and soon) pu branch from a new fork on repo.or.cz" He offered links to his new git development trees, and followed up in another email summarizing recent changes. He noted, "I based my branches on top of the last items published by Junio, and am hoping that he will be open to pulling directly from these before he starts working again. Junio obviously has the option not to pull from me, but if I do my job of interim maintainer well I can probably talk him into it. :)"

A discussion was raised as to whether or not GIT [story] would be a service that should be provided by development websites like SourceForge. Linus Torvalds suggested that this would be a good match-up. "The git architecture is admirably suited to an _untrusted_ central server," Linus explained, "ie exactly the SourceForge kind of setup." He went on to explain, "with git, developers don't have to trust SF, and if SF is down or something bad happens (disk crash, bad backups, whatever), you didn't 'lose' anything - the real development wasn't being done at SF anyway, it was a way to _connect_ the people who do real development."

As to whether or not this is likely to happen, Linus added, "it's possible that git usage won't expand all that much either. But quite frankly, I think git is a lot better than CVS (or even SVN) by now, and I wouldn't be surprised if it started getting some use outside of the git-only and kernel projects once people start getting more used to it. And so I'd be thrilled to have some site like SF support it."

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

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 ;)"

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

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

Andreas Schuldei asked in lkml if there was an easy a way for BitKeeper to backport stuff from the 2.5 to the 2.4 repositories. Like so many discussions, this rapidly veered off; from keeping separate BK repositories in sync, to the limitations of BitKeeper.

Much of the resulting discussion follows.

When Linux creator Linus Torvalds began using the BitKeeper (BK) source control tool for managing the 2.5 Linux development kernel [earlier story], one of the big fears people put forward was that all Linux kernel developers would eventually be forced to use this tool. (The BK license is a major source of contention.