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."
From: Linus Torvalds [email blocked] To: Git Mailing List [email blocked] Subject: Meet the new maintainer.. Date: Tue, 26 Jul 2005 20:24:07 -0700 (PDT) I'm sure some of you eagle-eyes have already noticed this, but for the last 24 hours the "owner" field on the main git project at www.kernel.org hasn't been pointing to yours truly any more. It says "Junio C Hamano" instead. The description may still say "Linus' core git plumbing", but I think that's just because Junio is being shy about things, and not very assertive, but the fact is, in the great tag-game of project maintainership, Junio is the new "it". I always said I didn't really want to maintain it in the long run, 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. Junio was the obvious choice, and since he accepted the maintainership position, it means that I don't have to track the git details as closely, and can go back to reading the linux kernel mailing list more actively. I'll just continue to send patches to Junio instead of applying them to my tree and pushing them out that way (or maybe I'll try to push any changes through my slaved git trees instead). In other words, I'm not "dropping" git, I just prefer working on it as a contributor rather than trying to keep track of everything that happens. So I don't think much will change, except I suspect Junio will drop fewer patches on the floor and ask for fewer re-sends or need less prodding ;) Linus
From: Junio C Hamano [email blocked] Subject: A note from the new GIT maintainer Date: Tue, 26 Jul 2005 23:04:18 -0700 As some of you seem to have noticed even before the announcement by Linus, the official GIT repository at kernel.org is now owned by me. As Linus said in his message, this does not mean he is leaving us, so please do not panic. I would like to thank everybody on the GIT list for what we have achieved so far. Getting your ideas blown away and still being able to feel happy about it is a privilege granted only to those who are fortunate enough to work with very talented people. It has been quite a fun experience for me. I would also like to thank Twin Sun Inc (my employer) and NEC for promising to support me working on GIT on a part time basis from now on. I expect to be spending 8 to 12 day-job hours per week; evenings and weekends are my own time as before. My tentative plan is to make Wednesdays and Saturdays my primary GIT days. Earlier, I was producing as many patches as ideas cross my mind, throwing all of them at the list to see which ones stick, relying on somebody with a good taste upstream to drop all the bad ones. Although it has been fun working that way with Linus, regrettably, I ended up wasting a lot of his time. I will slow down and be more careful as the "shepherd of the main repository" from now on. At least for now, you will see patches from me posted on the list like everybody else's, before they hit the main repository. In other words, I will make you my "adult supervision," so please help me out by raising objections, giving alternatives, or just plainly saying "your patch is ugly". Some of you may have also noticed that the main GIT repository has an extra branch, "pu" ("proposed updates"). My patches, along with patches from others I collect from the list that I intend to eventually apply, will first go there, before hitting the master branch. You can probably tell, by looking at this branch, what my priorities are, which patches are being considered, and responses to which ones I am still waiting for. Please note that I expect to rewind and rebase this branch quite often. I was planning to talk about the remaining tasks for 1.0 in this message when Linus asked me if I wanted to take over the core GIT project a couple of weeks ago. But I think we have done most, if not all, of what we would want to have in 1.0 since then. Of course there are still ongoing discussions for various improvements, but I feel that that can continue without blocking the 1.0 pre-release engineering process. Please keep bugfixes and documentation updates flowing. After the 1.0 release, I plan to start a branch for 1.0 maintenance, separate from the "master" branch. I think the intent of having GIT RPM support, which was done before me, was to force Pasky's hand to split core part from the Cogito package, but as the prerequisite for the split to happen, the interface to the core GIT part must be reasonably stable. We operated without even having any formal version numbers for quite some time, which I am sure made Pasky's life more miserable then it should have been. This must be rectified. I have not decided if we want to use even-odd scheme like the kernel used to have, or just keep the "master" a bleeding edge branch which is occasionally tagged. That's about it from me for now. Let's continue to have fun!
From: Ryan Anderson [email blocked] Subject: Git 1.0 Synopis (Draft v2) Date: Wed, 27 Jul 2005 06:01:23 -0400 [This is still a draft, but I think I incorporated the suggestons from the last attempt.] Source Code Management with Git 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. 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. Git uses the SHA1 hash algorithm to provide a content-addressable pseudo filesystem, complete with its own version of fsck. o Speed of use, both for the project maintainer, and the end-users, is a key development principle. o The history is stored as a directed acyclic graph, making long-lived branches and repeated merging simple. o A collection of related projects are building on the core Git project, either to provide an easier to use interface on top (StGit, Cogito, qgit, gitk, gitweb), or to take some of the underlying concepts and reimplement them directly into another system (Arch 2.0, Darcs-git). o Two, interchangeable, on-disk formats are used: o An efficient, packed format that saves spaced and network bandwidth. o An unpacked format, optimized for fast writes and incremental work. To get a copy of Git: Daily snapshots are available at: http://www.codemonkey.org.uk/projects/git-snapshots/git/ (Thanks to Dave Jones) Source tarballs and RPMs at: http://www.kernel.org/pub/software/scm/git/ Deb packages at: <insert url here> Or via Git itself: git clone http://www.kernel.org/pub/scm/git/git.git/ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ (rsync is generally faster for an initial pull) Git distributions contain a tutorial in the Documentation subdirectory. Additionally, the Kernel-Hacker's Git Tutorial at http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for that document) Git development takes place on the Git mailing list. To subscribe, send an email with just "subscribe git" in the body to [email blocked]. Mailing list archives are available at http://marc.theaimsgroup.com/?l=git Git results from the inspiration and frustration of Linus Torvalds, and the enthusiastic help of over 300 participants on the development mailing list. It is maintained by Junio C Hamano [email blocked]. 1 - Generated with the following, in a maildir folder: find . -type f | xargs grep -h "^From:" | perl -ne \ 'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l (This summary written by Ryan Anderson [email blocked]. Please bug him with any corrections or complaints.) -- Ryan Anderson sometimes Pug Majere
From: Junio C Hamano [email blocked] Subject: Re: Git 1.0 Synopis (Draft v2) Date: Wed, 27 Jul 2005 15:13:18 -0700 Ryan Anderson [email blocked] writes: > Source Code Management with Git Thanks for doing this. Generally looks excellent. > o Two, interchangeable, on-disk formats are used: > o An efficient, packed format that saves spaced and network > bandwidth. ??? "spaced" ??? > Or via Git itself: > git clone http://www.kernel.org/pub/scm/git/git.git/ > git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ > (rsync is generally faster for an initial pull) These need a target directory name to create, like this: git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ $new_dir git clone http://www.kernel.org/pub/scm/git/git.git/ $new_dir > Git results from the inspiration and frustration of Linus Torvalds, and > the enthusiastic help of over 300 participants on the development > mailing list. It is maintained by Junio C Hamano [email blocked]. Please drop the e-mail address here; you mention nobody else's. Well, dropping "the current maintainer" information altogether might be even better; the above to a casual reader sounds like Linus was frustrated and I wrote it for him, which is definitely not what we would like to say. I suspect it still has more code by Linus than anybody else (I stopped counting some time ago).