MaintNotes: retire in-repository html/man branches
Junio C Hamano committed
Oct 28, 2011 at 10:48 UTC
88d34b95732485db3302ab43693dc50dee66a0ef
1 file changed
+21
-31
MaintNotes
+21
-31
@@ -1,3 +1,5 @@
1
+Subject: A note from the maintainer
2
+
3
Welcome to git development community.
4
5
This message is written by the maintainer and talks about how Git
@@ -9,7 +11,7 @@ The development is primarily done on the Git mailing list. Help
11
requests, feature proposals, bug reports and patches should be sent to
12
the list address <git@vger.kernel.org>. You don't have to be
13
subscribed to send messages. The convention on the list is to keep
12
-everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
14
+everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
15
I am not subscribed".
16
17
Before sending patches, please read Documentation/SubmittingPatches
@@ -25,13 +27,13 @@ enough mental/time bandwidth to process them right at the moment, and
27
it often helps to wait until the list traffic becomes calmer before
28
sending such a reminder.
29
28
-The list archive is available at a few public sites as well:
30
+The list archive is available at a few public sites:
31
32
http://news.gmane.org/gmane.comp.version-control.git/
33
http://marc.theaimsgroup.com/?l=git
34
http://www.spinics.net/lists/git/
35
34
-and some people seem to prefer to read it over NNTP:
36
+Some people seem to prefer to read it over NNTP:
37
38
nntp://news.gmane.org/gmane.comp.version-control.git
39
@@ -55,12 +57,12 @@ bug report with just "git does not work". "I tried to do X but it did not
57
work" is not much better, neither is "I tried to do X and git did Y, which
58
is broken". It often is that what you expect is _not_ what other people
59
expect, and chances are that what you expect is very different from what
58
-people who have worked on git have expected (otherwise, the behavior
59
-would have been changed to match that expectation long time ago).
60
+people who have worked on git have expected---otherwise, the behavior
61
+would have been changed to match your expectation long time ago.
62
63
Please remember to always state
64
63
- - what you wanted to do;
65
+ - what you wanted to achieve;
66
67
- what you did (the version of git and the command sequence to reproduce
68
the behavior);
@@ -83,32 +85,21 @@ My public git.git repository is at:
85
https://github.com/git/git
86
https://code.google.com/p/git-core/
87
86
-Impatient people might have better luck with the latter two (there are a
87
-few other mirrors I push into at sourceforge and github as well).
88
+There are a few other mirrors I push into at sourceforge and github as
89
+well.
90
91
Their gitweb interfaces are found at:
92
93
http://git.kernel.org/?p=git/git.git
94
http://repo.or.cz/w/alt-git.git
95
94
-There are three branches in git.git repository that are not about the
95
-source tree of git: "html", "man", and "todo".
96
-
97
-The "html" and "man" are preformatted documentation from the tip of
98
-the "master" branch; the tip of "html" is visible at:
99
-
100
- http://www.kernel.org/pub/software/scm/git/docs/
101
- http://git-core.googlecode.com/git-history/html/git.html
102
-
103
-The above URL is the top-level documentation page, and it may have
104
-links to documentation of older releases.
96
+Preformatted documentation from the tip of the "master" branch can be
97
+found in:
98
106
-The "todo" branch was originally meant to contain a TODO list for me,
107
-but is mostly used to keep some helper scripts I use to maintain git.
108
-For example, the script that was used to maintain the two documentation
109
-branches are found there as dodoc.sh, which may be a good demonstration
110
-of how to use a post-update hook to automate a task after pushing into a
111
-repository.
99
+ git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
100
+ git://repo.or.cz/git-{htmldocs,manpages}.git/
101
+ https://code.google.com/p/git-{htmldocs,manpages}.git/
102
+ https://github.com/gitster/git-{htmldocs,manpages}.git/
103
104
There are four branches in git.git repository that track the source tree
105
of git: "master", "maint", "next", and "pu".
@@ -131,16 +122,15 @@ merged into "master" to propagate the fixes forward.
122
A new development does not usually happen on "master". When you send a
123
series of patches, after review on the mailing list, a separate topic
124
branch is forked from the tip of "master" and your patches are queued
134
-there, and kept out of "master" while people test it out. The quality of
125
+there, and kept out of "master" while people test it out. The quality of
126
topic branches are judged primarily by the mailing list discussions.
127
128
Topic branches that are in good shape are merged to the "next" branch. In
129
general, the "next" branch always contains the tip of "master". It might
139
-not be quite rock-solid production ready, but is expected to work more or
140
-less without major breakage. The "next" branch is where new and exciting
141
-things take place. A topic that is in "next" is expected to be polished to
142
-perfection before it is merged to "master" (that's why "master" can be
143
-expected to stay more stable than any released version).
130
+not be quite rock-solid, but is expected to work more or less without major
131
+breakage. The "next" branch is where new and exciting things take place. A
132
+topic that is in "next" is expected to be polished to perfection before it
133
+is merged to "master".
134
135
The "pu" (proposed updates) branch bundles all the remaining topic
136
branches. The topics on the branch are not complete, well tested, nor well