list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <>
Subject: A note from the maintainer
Date: Tue, 04 Oct 2011 19:22:58 -0700
Message-ID: <> (raw)

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites as well:

and some people seem to prefer to read it over NNTP:


When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

* Reporting bugs

When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work".  "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken".  It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).

Please remember to always state

 - what you wanted to do;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen;

 - what you expected to see; and

 - how the last two are different.

See for further

* Repositories, branches and documentation.

My public git.git repository is at:


Impatient people might have better luck with the latter two (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".

The "html" and "man" are preformatted documentation from the tip of
the "master" branch; the tip of "html" is visible at:

The above URL is the top-level documentation page, and it may have
links to documentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script that was used to maintain the two documentation
branches are found there as, which may be a good demonstration
of how to use a post-update hook to automate a task after pushing into a

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 very well tested and
ready to be used in a production setting.  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 1.7.7 done on
Sept 30, 2011. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

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 named with four dotted decimal, named
after the feature release they are updates to; the last such release was  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out.  The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.

* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:


 - gitk-git/ comes from Paul Mackerras's gitk project:


I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
   effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

             reply index

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05  2:22 Junio C Hamano [this message]
2011-10-15  5:47 ` Martin von Zweigbergk
2011-10-16  7:24   ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2019-02-26 17:15 Junio C Hamano
2017-11-28  5:20 Junio C Hamano
2017-10-30  6:19 Junio C Hamano
2017-10-30 12:50 ` Johannes Schindelin
2017-08-04 16:54 Junio C Hamano
2017-07-13 23:43 Junio C Hamano
2017-06-24 23:24 Junio C Hamano
2017-03-24 21:19 Junio C Hamano
2017-03-20 21:39 Junio C Hamano
2017-02-24 19:29 Junio C Hamano
2016-11-29 21:24 Junio C Hamano
2016-10-03 22:31 Junio C Hamano
2016-09-03  2:17 Junio C Hamano
2016-09-03 10:26 ` Jakub Narębski
2016-09-07 16:16   ` Junio C Hamano
2016-08-12 19:55 Junio C Hamano
2016-08-12 22:42 ` Eric Wong
2016-08-13  8:10   ` Jeff King
2016-08-13  9:04     ` Eric Wong
2016-08-13 11:14       ` Jeff King
2016-08-14  1:27         ` Eric Wong
2016-08-14  2:12           ` Eric Wong
2016-08-14 12:23             ` Jeff King
2016-08-14 12:19           ` Jeff King
2016-08-14 15:00           ` Philip Oakley
2016-08-14 22:52             ` Eric Wong
2016-07-11 20:14 Junio C Hamano
2016-06-13 19:45 Junio C Hamano
2016-05-19 17:48 Junio C Hamano
2016-04-29 22:04 Junio C Hamano
2016-03-28 22:42 Junio C Hamano
2016-02-06  0:07 Junio C Hamano
2016-01-04 23:44 Junio C Hamano
2015-11-05 23:14 Junio C Hamano
2015-11-06 10:50 ` Xue Fuqiao
2015-11-06 17:38   ` Junio C Hamano
2015-09-28 23:20 Junio C Hamano
2015-08-28 21:12 Junio C Hamano
2015-07-15 21:43 Junio C Hamano
2015-04-30 19:51 Junio C Hamano
2015-05-08 14:46 ` Christian Couder
2015-05-08 16:25   ` Junio C Hamano
2015-03-23 21:38 Junio C Hamano
2015-03-06 23:33 Junio C Hamano
2015-02-05 22:53 Junio C Hamano
2014-11-26 23:09 Junio C Hamano
2013-03-13 20:26 Junio C Hamano
2013-01-28 20:48 Junio C Hamano
2013-01-01  0:27 Junio C Hamano
2012-12-10 23:16 Junio C Hamano
2012-10-21 22:10 Junio C Hamano
2012-10-08 20:08 Junio C Hamano
2012-09-18 23:14 Junio C Hamano
2012-08-20  3:16 Junio C Hamano
2012-06-19 23:53 Junio C Hamano
2012-03-06  7:10 Junio C Hamano
2012-01-27 21:31 [ANNOUNCE] Git 1.7.9 Junio C Hamano
2012-01-27 21:41 ` A note from the maintainer Junio C Hamano
2011-10-24 15:32 Junio C Hamano
2011-08-24 23:51 Junio C Hamano
2011-04-25 21:05 A Note from the Maintainer Junio C Hamano
2011-01-31  5:51 A note from the maintainer Junio C Hamano
2010-09-19  1:28 Junio C Hamano
2010-07-21 22:18 Junio C Hamano
2010-02-13  1:24 Junio C Hamano
2010-01-01  0:09 Junio C Hamano
2009-07-29 21:15 Junio C Hamano
2009-05-07  7:09 Junio C Hamano
2009-05-07 13:40 ` Baz
2009-05-07 16:30   ` Junio C Hamano
2009-03-04 19:52 Junio C Hamano
2008-12-25  6:48 Junio C Hamano
2008-08-17 21:16 [ANNOUNCE] GIT 1.6.0 Junio C Hamano
2008-08-17 23:58 ` A note from the maintainer Junio C Hamano
2008-06-18 23:24 [ANNOUNCE] GIT 1.5.6 Junio C Hamano
2008-06-19  7:24 ` A note from the maintainer Junio C Hamano
2008-07-14  5:51   ` Junio C Hamano
2008-04-09  9:44 Junio C Hamano
2008-02-17  9:16 Junio C Hamano
2008-03-09 10:57 ` Junio C Hamano
2008-02-02  4:35 Junio C Hamano
2008-02-02 11:06 ` Jakub Narebski
2008-01-08  8:57 Junio C Hamano
2008-01-08  9:57 ` Jakub Narebski
2008-01-08 10:03   ` Junio C Hamano
2007-09-02  6:31 [ANNOUNCE] GIT 1.5.3 Junio C Hamano
2007-09-02  6:34 ` A note from the maintainer Junio C Hamano
2007-04-04  9:12 [ANNOUNCE] GIT 1.5.1 Junio C Hamano
2007-04-04 18:26 ` A note from the maintainer Junio C Hamano
2007-05-20  9:54   ` Junio C Hamano
2007-02-14  3:14 [ANNOUNCE] GIT 1.5.0 Junio C Hamano
2007-02-16 22:31 ` A note from the maintainer Junio C Hamano
2007-02-17  2:35   ` Johannes Schindelin
2007-02-23  6:03     ` Junio C Hamano
2007-01-02  3:31 Junio C Hamano
2007-01-02  3:47 ` Shawn O. Pearce
2006-10-24  9:16 Junio C Hamano
2006-10-24  9:37 ` Jakub Narebski

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox