Subject: A note from the maintainer

From: Junio C Hamano <[email-masked]>
Date: Tue, 24 Oct 2006 02:16:43 -0700

Since there seem to be many new people on the git list, I
thought it might be worthwhile to talk about how git.git is
managed, and how you can work with it.

* Mailing list.

The development is primarily done on this mailing list you are
reading right now.

If you have patches, please send them to the list, following
Documentation/SubmittingPatches.

The list is available at various public sites as well:

	http://news.gmane.org/gmane.comp.version-control.git
	http://marc.theaimsgroup.com/?l=git

Many active members of development community hang around on #git
IRC channel as well.  Its log is available at:

	http://colabti.de/irclogger/irclogger_logs/git

[jc: Does anybody know a shortcut for "Today's" page on this
 site?  It irritates me having to click the latest link on this
 page to get to the latest]

* Repositories and branches.

My public git.git repository is at:

	git://git.kernel.org/pub/scm/git/git.git/

It is mirrored at Pasky's repo.or.cz as well.

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one is meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
I would have liked.  It also contains some helper scripts I
use to maintain it.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

	http://www.kernel.org/pub/software/scm/git/docs/

The script to auto-maintain these two documentation branches are
found in "todo" branch as dodoc.sh script, if you are interested.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.4.3 done on Oct 18th.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.3.2 was done tonight.  Usually new development will never
go to this branch.  This branch is also pulled into "master" to
propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often you
found your own itch to scratch, does not usually happen on
"master", however.  Instead, it is forked into a separate topic
branch from the tip of "master", and first tested in isolation;
I may make minimum fixups at this point.  Usually there are a
handful such topic branches that are running ahead of "master"
in git.git repository.  I do not publish the tip of these
branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry
about and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category with "master".  In general it should always
contain the tip of "master".  They may not be quite production
ready, but are expected to work more or less without major
breakage.  I usually use "next" version of git for my own work.
"next" is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).

The "pu" (proposed updates) branch bundles all the remaining
topic branches.  The topic branches and "pu" are subject to
rebasing in general.  Especially "pu" is almost always rewound
to the tip of "next" and reconstructed to contain the remaining
topic branches.  What this means is that immediately after
cloning from git.git, it is advisable to mark "pu" in your
remotes/origin that it does not necessarily fast-forwards, like
this:

	$ cat .git/remotes/origin
        URL: git://git.kernel.org/pub/scm/git/git.git
        Pull: refs/heads/master:refs/heads/origin
        Pull: refs/heads/maint:refs/heads/maint
        Pull: refs/heads/next:refs/heads/next
        Pull: +refs/heads/pu:refs/heads/pu

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  This is done by:

	git checkout next
        git pull . that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is _expected_ to be tweaked and fixed
to perfection before it is merged to "master".  It is done by:

	git checkout master
        git pull . that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" _is_ such a guarantee), or even
in _any_ future release.  There even was a case that a topic
needed a few reverting before graduating to "master".