mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <>
Subject: A note from the maintainer
Date: Thu, 30 Apr 2015 12:51:16 -0700
Message-ID: <> (raw)

Welcome to the 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 say "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 may be a sign that those who can evaluate
your patch 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:

For those who 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 be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

There is a volunteer-run newsletter to serve our community (visit to find "Git Rev News").  If you want to help
its publication, please contact Christian and/or Thomas.

Git is a member project of software freedom conservancy, a non-profit
organization (  To reach a committee of
liaisons to the conservancy, contact them 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 used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

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

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See for further

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <>.

* Repositories, branches and documentation.

My public git.git repositories are at:


A few web interfaces are found at:

Preformatted documentation from the tip of the "master" branch can be
found in:


Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

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.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.4.0 done on Apr 30th, 2015. 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 used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.3.4" is the
fourth maintenance release for the "2.3" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

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

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a 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 to "next".

* 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:


 - po/ comes from the localization coordinator, Jiang Xin:

         reply index

Thread overview: 88+ messages in thread (expand / mbox.gz / Atom feed / [top])
2006-10-24  9:16 Junio C Hamano
2006-10-24  9:37 ` Jakub Narebski
2007-01-02  3:31 Junio C Hamano
2007-01-02  3:47 ` Shawn O. Pearce
     [not found] <>
2007-02-16 22:31 ` Junio C Hamano
2007-02-17  2:35   ` Johannes Schindelin
2007-02-23  6:03     ` Junio C Hamano
     [not found] <>
2007-04-04 18:26 ` Junio C Hamano
2007-05-20  9:54   ` Junio C Hamano
     [not found] <>
2007-09-02  6:34 ` Junio C Hamano
2008-01-08  8:57 Junio C Hamano
2008-01-08  9:57 ` Jakub Narebski
2008-01-08 10:03   ` Junio C Hamano
2008-02-02  4:35 Junio C Hamano
2008-02-02 11:06 ` Jakub Narebski
2008-02-17  9:16 Junio C Hamano
2008-03-09 10:57 ` Junio C Hamano
2008-04-09  9:44 Junio C Hamano
     [not found] <>
2008-06-19  7:24 ` Junio C Hamano
2008-07-14  5:51   ` Junio C Hamano
     [not found] <>
2008-08-17 23:58 ` Junio C Hamano
2008-12-25  6:48 Junio C Hamano
2009-03-04 19:52 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-07-29 21:15 Junio C Hamano
2010-01-01  0:09 Junio C Hamano
2010-02-13  1:24 Junio C Hamano
2010-07-21 22:18 Junio C Hamano
2010-09-19  1:28 Junio C Hamano
2011-01-31  5:51 Junio C Hamano
2011-04-25 21:05 Junio C Hamano
2011-08-24 23:51 Junio C Hamano
2011-10-05  2:22 Junio C Hamano
2011-10-15  5:47 ` Martin von Zweigbergk
2011-10-16  7:24   ` Junio C Hamano
2011-10-24 15:32 Junio C Hamano
     [not found] <>
2012-01-27 21:41 ` Junio C Hamano
2012-03-06  7:10 Junio C Hamano
2012-06-19 23:53 Junio C Hamano
2012-08-20  3:16 Junio C Hamano
2012-09-18 23:14 Junio C Hamano
2012-10-08 20:08 Junio C Hamano
2012-10-21 22:10 Junio C Hamano
2012-12-10 23:16 Junio C Hamano
2013-01-01  0:27 Junio C Hamano
2013-01-28 20:48 Junio C Hamano
2013-03-13 20:26 Junio C Hamano
2014-11-26 23:09 Junio C Hamano
2015-02-05 22:53 Junio C Hamano
2015-03-06 23:33 Junio C Hamano
2015-03-23 21:38 Junio C Hamano
2015-04-30 19:51 Junio C Hamano [this message]
2015-05-08 14:46 ` Christian Couder
2015-05-08 16:25   ` Junio C Hamano
2015-07-15 21:43 Junio C Hamano
2015-08-28 21:12 Junio C Hamano
2015-09-28 23:20 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
2016-01-04 23:44 Junio C Hamano
2016-02-06  0:07 Junio C Hamano
2016-03-28 22:42 Junio C Hamano
2016-04-29 22:04 Junio C Hamano
2016-05-19 17:48 Junio C Hamano
2016-06-13 19:45 Junio C Hamano
2016-07-11 20:14 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-09-03  2:17 Junio C Hamano
2016-09-03 10:26 ` Jakub Narębski
2016-09-07 16:16   ` Junio C Hamano
2016-10-03 22:31 Junio C Hamano
2016-11-29 21:24 Junio C Hamano
2017-02-24 19:29 Junio C Hamano
2017-03-20 21:39 Junio C Hamano
2017-03-24 21:19 Junio C Hamano

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 to all the recipients 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 mailing list mirror (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