40ec0c59ea · matheusbsbs/matheus-bagliano

@@ -7,8 +7,8 @@ This message is written by the maintainer and talks about how Git

7 project is managed, and how you can work with it.

8

9 The current maintainer is Junio C Hamano <gitster@pobox.com>. Spam

10 -filters learned that legitimate messages come only from a very few

11 -sender addresses that are known to be good to this address, and all

10 +filters learned that legitimate messages come to this address only

11 +from a very few sender addresses that are known to be good, and all

12 other messages are likely to be spam unless they are also sent to the

13 mailing list at the same time (i.e. "Reply-all" to the list message

14 would reach the mailbox, but "Reply" will likely be thrown into the

@@ -185,14 +185,14 @@ named with three dotted decimal digits (e.g., "1.8.5"), but we have

185 switched the versioning scheme and "feature releases" are named with

186 three-dotted decimal digits that ends with ".0" (e.g., "1.9.0").

187

188 -The last such release was 2.51 done on Aug 18th, 2025. We aim to keep

188 +The last such release was 2.52 done on Nov 17th, 2025. We aim to keep

189 that the tip of the "master" branch is always more stable than any of

190 the released versions.

191

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

193 -"master" at that point. Obvious and safe fixes after a feature

194 -release are merged to this branch and maintenance releases are cut

195 -from it. Usually the topic branches that contain these fixes are

193 +"master" at that point. Obvious and safe fixes for bugs in the latest

194 +feature release are merged to this branch and maintenance releases are

195 +cut from it. Usually the topic branches that contain these fixes are

196 merged to the "master" branch first, before getting merged to the

197 "maint" branch, to reduce the chance of last-minute issues, but

198 things like embargoed security fixes may first appear in the "maint"

@@ -203,9 +203,11 @@ release for "1.8.5" feature release). These days, maintenance releases

203 are named by incrementing the last digit of three-dotted decimal name

204 (e.g., "2.47.1" was the second maintenance release for the "2.47" series).

205

206 -New features almost never go to the "maint" branch. It is merged into

207 -"master" primarily to propagate the description in the release notes

208 -forward.

206 +New features almost never go to the "maint" branch, although changes

207 +to help Git developers themselves, including CI updates, are often

208 +merged down even if they are not bugfixes at all. The "maint" branch

209 +is merged up into the "master" branch, primarily to propagate the

210 +description in the release notes forward.

211

212 When you send a series of patches, after review discussions on the

213 mailing list, a separate topic branch is forked from the tip of

@@ -225,30 +227,28 @@ this process by building & using the "next" branch for your daily

227 work, and reporting any new bugs you find to the mailing list, before

228 the breakage is merged down to the "master".

229

228 -The "seen" (formerly "pu", proposed updates) branch bundles the

229 -remaining topic branches the maintainer happens to have seen to remind

230 -the maintainer that the topics in them might become interesting when

231 -they are polished.

232 -

233 -The contributors can use it to anticipate what topics from others

234 -may cause conflict with their own work, and find people who are

235 -working on these topics to talk to before the potential conflicts

236 -get out of control. It would be a good idea to fork from maint or

237 -master to grow a topic and to test (1) it by itself, (2) a temporary

238 -merge of it to 'next' and (3) a temporary merge to it to 'seen',

230 +The "seen" branch bundles the remaining topic branches that the

231 +maintainer happens to have seen to remind the maintainer that the

232 +topics in them might become interesting when they are polished. A

233 +topic in "seen" can and does get discarded before it gets merged to

234 +"next" if its idea does not pan out, just like a topic can wither on

235 +the list without anybody supporting it. Please do not read anything

236 +more than "the maintainer has seen it and found it potentially

237 +interesting" into a topic being in "seen".

238 +

239 +The contributors can use the "seen" branch to anticipate what topics

240 +by others may cause conflicts with their own work, and find people who

241 +are working on these topics to talk to before the potential conflicts

242 +get out of control. It would be a good idea to fork your work from

243 +maint or master and to (1) test it by itself, (2) test a temporary

244 +merge of it to 'next' and (3) test a temporary merge to it to 'seen',

245 before publishing it.

246

241 -Consider that a topic only in "seen" is not part of "git" yet. When a

242 -topic that was in "seen" proves to be in a testable shape, it is

243 -merged to "next".

244 -

247 You can run "git log --first-parent master..seen" to see what topics

246 -are currently in flight. Sometimes, a topic that looked promising

247 -proves to be a bad idea and the topic gets dropped from "seen" in such

248 -a case. The output of the above "git log" talks about a "jch" branch,

249 -which is an early part of the "seen" branch; that branch contains all

250 -topics that are in "next" and a bit more (but not all of "seen") and

251 -is used by the maintainer for his daily work.

248 +are currently in flight. The output of the above "git log" talks

249 +about a "jch" branch, which is an early part of the "seen" branch;

250 +that branch contains all topics that are in "next" and a bit more (but

251 +not all of "seen") and is used by the maintainer for his daily work.

252

253 The two branches "master" and "maint" are never rewound, and "next"

254 usually will not be either. After a feature release is made from

MaintNotes - update post 2.52