git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: A note from the maintainer
Date: Fri, 16 Feb 2007 14:31:39 -0800	[thread overview]
Message-ID: <7vire120qc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 7vlkj1v3av.fsf@assigned-by-dhcp.cox.net

It has been a while since I sent this message out the last time,
so it may be a good time to send it with updates again.  There
seem to be some new people on the git list, especially now the
big release is out.

This message talks about how git.git is managed, and how you can
work with it.


* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel.  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.]


The development however 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.

I usually read all patches posted to the list, and follow almost
all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously
not perfect.  If you sent a patch that you did not hear from
anybody for three days, that is a very good indication that it
was dropped on the floor --- please do not hesitate to remind
me.

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

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

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

	nntp://news.gmane.org/gmane.comp.version-control.git


* Repositories, branches and documentation.

My public git.git repository is at:

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

This is mirrored at Pasky's site at

	git://repo.or.cz/git.git/

but the first has a few hours mirroring delay after I publish
updates, and the latter, being a mirror of former, lags behind
it further.  Immediately after I publish to the primary
repository at kernel.org, I also push into an alternate here:

	git://repo.or.cz/alt-git.git/

Impatient people would have better lack with the last one (but
the last repository does not have "html", "man" and "todo"
branches, described next).


There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was 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
it could/should be.  It also contains some helper scripts I use
to maintain git.

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/

Starting from 1.5.0, the top-level documentation page has links
to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

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.5.0 done on Feb 14th this year.  The
codename for that release is not "snog".

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.4.4, and I am expecting to cut v1.5.0.1 sometime soon.
Usually new development will never go to this branch.  This
branch is also merged 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 by
somebody who found his or her 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.  In general it should always contain the tip of
"master".  They might 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, so it cannot be
_that_ broken to prevent me from pushing the changes out.
The "next" branch 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 remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

	git checkout next
        git merge 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".  However, being in
"next" is not a guarantee to appear in the next release (being
in "master" is such a guarantee, unless it is later found
seriously broken and reverted), or even in any future release.
There even were cases that topics needed a few reverting before
graduating to "master", or a topic that already was in "next"
were reverted from "next" because fatal flaws were found in them
later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


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

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

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

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Packerras, at:

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

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 on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
   Rene Scharfe on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff on cvsserver and cvsimport.

 - Paul Packerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

  parent reply	other threads:[~2007-02-16 22:31 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14  3:14 [ANNOUNCE] GIT 1.5.0 Junio C Hamano
2007-02-14  9:06 ` Andy Parkins
2007-02-14  9:35   ` Junio C Hamano
2007-02-14  9:48     ` Junio C Hamano
2007-02-14 12:42 ` Matthieu Moy
2007-02-14 14:57 ` Bill Lear
2007-02-14 16:45   ` Linus Torvalds
2007-02-15  1:55 ` Jakub Narebski
2007-02-15  2:11   ` Shawn O. Pearce
2007-02-16 22:31 ` Junio C Hamano [this message]
2007-02-17  2:35   ` A note from the maintainer Johannes Schindelin
2007-02-23  6:03     ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2023-03-13 18:02 Junio C Hamano
2022-12-11  5:18 Junio C Hamano
2022-10-03 17:26 Junio C Hamano
2022-07-12 17:08 Junio C Hamano
2022-06-27 18:22 Junio C Hamano
2022-04-18 17:03 Junio C Hamano
2022-01-24 19:25 Junio C Hamano
2021-08-16 23:06 Junio C Hamano
2021-06-06 14:14 Junio C Hamano
2021-03-26 22:53 Junio C Hamano
2021-03-27  6:59 ` Bagas Sanjaya
2021-03-15 19:34 Junio C Hamano
2020-12-28 19:09 Junio C Hamano
2020-10-29 22:27 Junio C Hamano
2020-07-17 20:27 Junio C Hamano
2020-06-01 16:33 Junio C Hamano
2020-06-14 11:26 ` Kaartic Sivaraam
2020-06-15 16:58   ` Junio C Hamano
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-10-05  2:22 Junio C Hamano
2011-10-15  5:47 ` Martin von Zweigbergk
2011-10-16  7:24   ` 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-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 publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7vire120qc.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).