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.[1]  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.[1]  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).

• Archive of above thread [1] [2]