You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
227 lines
9.2 KiB
227 lines
9.2 KiB
Subject: A note from the maintainer |
|
|
|
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 <git@vger.kernel.org>. 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 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: |
|
|
|
http://news.gmane.org/gmane.comp.version-control.git/ |
|
http://marc.theaimsgroup.com/?l=git |
|
http://www.spinics.net/lists/git/ |
|
|
|
For those who prefer to read it over NNTP (including the maintainer): |
|
|
|
nntp://news.gmane.org/gmane.comp.version-control.git |
|
|
|
When you point at a message in a mailing list archive, using |
|
gmane is often the easiest to follow by readers, like this: |
|
|
|
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 |
|
|
|
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: |
|
|
|
http://colabti.org/irclogger/irclogger_log/git |
|
|
|
* 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 http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further |
|
hints. |
|
|
|
* Repositories, branches and documentation. |
|
|
|
My public git.git repositories are at: |
|
|
|
git://git.kernel.org/pub/scm/git/git.git/ |
|
https://kernel.googlesource.com/pub/scm/git/git |
|
git://repo.or.cz/alt-git.git/ |
|
https://github.com/git/git/ |
|
https://code.google.com/p/git-core/ |
|
git://git.sourceforge.jp/gitroot/git-core/git.git/ |
|
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/ |
|
|
|
A few web interfaces are found at: |
|
|
|
http://git.kernel.org/?p=git/git.git |
|
https://kernel.googlesource.com/pub/scm/git/git |
|
http://repo.or.cz/w/alt-git.git |
|
|
|
Preformatted documentation from the tip of the "master" branch can be |
|
found in: |
|
|
|
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/ |
|
git://repo.or.cz/git-{htmldocs,manpages}.git/ |
|
https://code.google.com/p/git-{htmldocs,manpages}.git/ |
|
https://github.com/gitster/git-{htmldocs,manpages}.git/ |
|
|
|
You can browse the HTML manual pages at: |
|
|
|
http://git-htmldocs.googlecode.com/git/git.html |
|
|
|
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.8.2 done on Mar 13, 2013. 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 |
|
1.8.1.5. New features never go to this 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 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 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. |
|
|
|
|
|
* 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: |
|
|
|
git://repo.or.cz/git-gui.git |
|
|
|
- gitk-git/ comes from Paul Mackerras's gitk project: |
|
|
|
git://ozlabs.org/~paulus/gitk |
|
|
|
- po/ comes from the localization coordinator, Jiang Xin: |
|
|
|
https://github.com/git-l10n/git-po/ |
|
|
|
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 for helping with general |
|
design and implementation issues and reviews on the mailing list. |
|
|
|
- Shawn and Nicolas Pitre for helping with packfile design and |
|
implementation issues. |
|
|
|
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for |
|
cvsserver and cvsimport. |
|
|
|
- Paul Mackerras for gitk. |
|
|
|
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn. |
|
|
|
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4. |
|
|
|
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe |
|
Bilotta for maintaining and enhancing gitweb. |
|
|
|
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang |
|
Xin for volunteering to be the l10n coordinator. |
|
|
|
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related |
|
Porcelains. |
|
|
|
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for |
|
documentation (and countless others for proofreading and fixing). |
|
|
|
- Alexandre Julliard for 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, Pat Thoyts 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.
|
|
|