0ee949b815 · matheusbsbs/matheus-bagliano

@@ -1,23 +1,13 @@

1 -It has been a while since I sent this message out the last time,

2 -so it may be a good time to send it with updates again. There

3 -seem to be some new people on the git list, especially now the

4 -big release is out.

5 -

6 -This message talks about how git.git is managed, and how you can

7 -work with it.

8 -

1 +Now a new feature release is out, it's time to welcome new

2 +people to the list. This message talks about how git.git is

3 +managed, and how you can work with it.

4

5 * IRC and Mailing list

6

7 Many active members of development community hang around on #git

8 IRC channel. Its log is available at:

9

15 - http://colabti.de/irclogger/irclogger_logs/git

16 -

17 -[jc: Does anybody know a shortcut for "Today's" page on this

18 - site? It irritates me having to click the latest link on this

19 - page to get to the latest.]

20 -

10 + http://colabti.de/irclogger/irclogger_log/git

11

12 The development however is primarily done on this mailing list

13 you are reading right now. If you have patches, please send

@@ -33,36 +23,35 @@ me.

23

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

25

36 - http://marc.theaimsgroup.com/?l=git

37 - http://news.gmane.org/gmane.comp.version-control.git

26 + http://marc.theaimsgroup.com/?l=git

27 + http://news.gmane.org/gmane.comp.version-control.git

28

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

30

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

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

32

33

34 * Repositories, branches and documentation.

35

36 My public git.git repository is at:

37

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

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

39

40 This is mirrored at Pasky's site at

41

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

42 + git://repo.or.cz/git.git/

43

44 but the first has a few hours mirroring delay after I publish

45 updates, and the latter, being a mirror of former, lags behind

46 it further. Immediately after I publish to the primary

47 repository at kernel.org, I also push into an alternate here:

48

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

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

50

61 -Impatient people would have better lack with the last one (but

51 +Impatient people would have better luck with the last one (but

52 the last repository does not have "html", "man" and "todo"

53 branches, described next).

54

65 -

55 There are three branches in git.git repository that are not

56 about the source tree of git: "todo", "html" and "man". The

57 first one was meant to contain TODO list for me, but I am not

@@ -74,10 +63,10 @@ The "html" and "man" are autogenerated documentation from the

63 tip of the "master" branch; the tip of "html" is extracted to be

64 visible at kernel.org at:

65

77 - http://www.kernel.org/pub/software/scm/git/docs/

66 + http://www.kernel.org/pub/software/scm/git/docs/

67

79 -Starting from 1.5.0, the top-level documentation page has links

80 -to documentation of older releases.

68 +The above URL is the top-level documentation page, and it has

69 +links to documentation of older releases.

70

71 The script to maintain these two documentation branches are

72 found in "todo" branch as dodoc.sh, if you are interested. It

@@ -87,37 +76,34 @@ a task.

76 There are four branches in git.git repository that track the

77 source tree of git: "master", "maint", "next", and "pu".

78

90 -The "master" branch is meant to contain what are reasonably

79 +The "master" branch is meant to contain what are very well

80 tested and ready to be used in a production setting. There

81 could occasionally be minor breakages or brown paper bag bugs

82 but they are not expected to be anything major. Every now and

83 then, a "feature release" is cut from the tip of this branch and

84 they typically are named with three dotted decimal digits. The

96 -last such release was v1.5.0 done on Feb 14th this year. The

97 -codename for that release is not "snog".

85 +last such release was v1.5.1 done on April 4th this year.

86

87 Whenever a feature release is made, "maint" branch is forked off

88 from "master" at that point. Obvious, safe and urgent fixes

89 after a feature release are applied to this branch and

90 maintenance releases are cut from it. The maintenance releases

103 -are typically named with four dotted decimal, named after the

104 -feature release they are updates to; the last such release was

105 -v1.4.4.4, and I am expecting to cut v1.5.0.1 sometime soon.

106 -Usually new development will never go to this branch. This

107 -branch is also merged into "master" to propagate the fixes

108 -forward.

91 +are named with four dotted decimal, named after the feature

92 +release they are updates to; the last such release was v1.5.0.7.

93 +New features never goes to this branch. This branch is also

94 +merged into "master" to propagate the fixes forward.

95

96 A trivial and safe enhancement goes directly on top of "master".

97 A new development, either initiated by myself or more often by

98 somebody who found his or her own itch to scratch, does not

113 -usually happen on "master", however. Instead, it is forked into

114 -a separate topic branch from the tip of "master", and first

99 +usually happen on "master", however. Instead, a separate topic

100 +branch is forked from the tip of "master", and it first is

101 tested in isolation; I may make minimum fixups at this point.

102 Usually there are a handful such topic branches that are running

103 ahead of "master" in git.git repository. I do not publish the

104 tip of these branches in my public repository, however, partly

105 to keep the number of branches that downstream developers need

120 -to worry about and primarily because I am lazy.

106 +to worry about low, and primarily because I am lazy.

107

108 I judge the quality of topic branches, taking advices from the

109 mailing list discussions. Some of them start out as "good idea

@@ -128,16 +114,18 @@ or less done and can now be tested by wider audience". Luckily,

114 most of them start out in the latter, better shape.

115

116 The "next" branch is to merge and test topic branches in the

131 -latter category. In general it should always contain the tip of

132 -"master". They might not be quite production ready, but are

133 -expected to work more or less without major breakage. I usually

134 -use "next" version of git for my own work, so it cannot be

135 -_that_ broken to prevent me from pushing the changes out.

117 +latter category. In general, the branch always contains the tip

118 +of "master". It might not be quite rock-solid production ready,

119 +but is expected to work more or less without major breakage. I

120 +usually use "next" version of git for my own work, so it cannot

121 +be _that_ broken to prevent me from pushing the changes out.

122 The "next" branch is where new and exciting things take place.

123

124 The above three branches, "master", "maint" and "next" are never

139 -rewound, so you should be able to safely track them (that means

140 -the topics that have been merged into "next" are not rebased).

125 +rewound, so you should be able to safely track them (this

126 +automatically means the topics that have been merged into "next"

127 +are not rebased, and you can find the tip of topic branches you

128 +are interested in out of "git log next" output).

129

130 The "pu" (proposed updates) branch bundles all the remainder of

131 topic branches. The "pu" branch, and topic branches that are

@@ -146,21 +134,27 @@ only in "pu", are subject to rebasing in general.

134 When a topic that was in "pu" proves to be in testable shape, it

135 graduates to "next". I do this with:

136

149 - git checkout next

137 + git checkout next

138 git merge that-topic-branch

139

140 Sometimes, an idea that looked promising turns out to be not so

141 hot and the topic can be dropped from "pu" in such a case.

142

143 A topic that is in "next" is expected to be tweaked and fixed to

156 -perfection before it is merged to "master". However, being in

157 -"next" is not a guarantee to appear in the next release (being

158 -in "master" is such a guarantee, unless it is later found

159 -seriously broken and reverted), or even in any future release.

160 -There even were cases that topics needed a few reverting before

161 -graduating to "master", or a topic that already was in "next"

162 -were reverted from "next" because fatal flaws were found in them

163 -later.

144 +perfection before it is merged to "master". Similarly to the

145 +above I do it with this:

146 +

147 + git checkout master

148 + git merge that-topic-branch

149 + git branch -d that-topic-branch

150 +

151 +However, being in "next" is not a guarantee to appear in the

152 +next release (being in "master" is such a guarantee, unless it

153 +is later found seriously broken and reverted), or even in any

154 +future release. There even were cases that topics needed a few

155 +reverting before graduating to "master", or a topic that already

156 +was in "next" were reverted from "next" because fatal flaws were

157 +found in them later.

158

159 Starting from v1.5.0, "master" and "maint" have release notes

160 for the next release in Documentation/RelNotes-* files, so that

@@ -185,7 +179,7 @@ have their own authoritative repository and maintainers:

179

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

181

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

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

183

184 I would like to thank everybody who helped to raise git into the

185 current shape. Especially I would like to thank the git list

@@ -208,5 +202,3 @@ relying on heavily:

202 - Jakub Narebski and Luben Tuikov on gitweb.

203

204 - J. Bruce Fields on documentaton issues.

211 -

212 -

MaintNotes: 2007-04-04 edition