averello/git-mirror
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2025-12-12 20:36:24 +01:00
Code Issues Packages Projects Releases Wiki Activity

MaintNotes - update post 2.52

Browse Source
This commit is contained in:
Junio C Hamano
2025-11-18 14:21:05 -08:00
parent cb4b603d97
commit 40ec0c59ea
1 changed files with 29 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
MaintNotes
View File

@@ -7,8 +7,8 @@ This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
The current maintainer is Junio C Hamano <gitster@pobox.com>. Spam
filters learned that legitimate messages come only from a very few
sender addresses that are known to be good to this address, and all
filters learned that legitimate messages come to this address only
from a very few sender addresses that are known to be good, and all
other messages are likely to be spam unless they are also sent to the
mailing list at the same time (i.e. "Reply-all" to the list message
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
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g., "1.9.0").
The last such release was 2.51 done on Aug 18th, 2025. We aim to keep
The last such release was 2.52 done on Nov 17th, 2025. We aim to keep
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 and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it. Usually the topic branches that contain these fixes are
"master" at that point. Obvious and safe fixes for bugs in the latest
feature release are merged to this branch and maintenance releases are
cut from it. Usually the topic branches that contain these fixes are
merged to the "master" branch first, before getting merged to the
"maint" branch, to reduce the chance of last-minute issues, but
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
are named by incrementing the last digit of three-dotted decimal name
(e.g., "2.47.1" was the second maintenance release for the "2.47" series).
New features almost never go to the "maint" branch. It is merged into
"master" primarily to propagate the description in the release notes
forward.
New features almost never go to the "maint" branch, although changes
to help Git developers themselves, including CI updates, are often
merged down even if they are not bugfixes at all. The "maint" branch
is merged up into the "master" branch, primarily to propagate the
description in the release notes forward.
When you send a series of patches, after review discussions on the
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
work, and reporting any new bugs you find to the mailing list, before
the breakage is merged down to the "master".
The "seen" (formerly "pu", proposed updates) branch bundles the
remaining topic branches the maintainer happens to have seen to remind
the maintainer that the topics in them might become interesting when
they are polished.
The "seen" branch bundles the remaining topic branches that the
maintainer happens to have seen to remind the maintainer that the
topics in them might become interesting when they are polished. A
topic in "seen" can and does get discarded before it gets merged to
"next" if its idea does not pan out, just like a topic can wither on
the list without anybody supporting it. Please do not read anything
more than "the maintainer has seen it and found it potentially
interesting" into a topic being in "seen".
The contributors can use it to anticipate what topics from others
may cause conflict with their own work, and find people who are
working on these topics to talk to before the potential conflicts
get out of control. It would be a good idea to fork from maint or
master to grow a topic and to test (1) it by itself, (2) a temporary
merge of it to 'next' and (3) a temporary merge to it to 'seen',
The contributors can use the "seen" branch to anticipate what topics
by others may cause conflicts with their own work, and find people who
are working on these topics to talk to before the potential conflicts
get out of control. It would be a good idea to fork your work from
maint or master and to (1) test it by itself, (2) test a temporary
merge of it to 'next' and (3) test a temporary merge to it to 'seen',
before publishing it.
Consider that a topic only in "seen" is not part of "git" yet. When a
topic that was in "seen" proves to be in a testable shape, it is
merged to "next".
You can run "git log --first-parent master..seen" to see what topics
are currently in flight. Sometimes, a topic that looked promising
proves to be a bad idea and the topic gets dropped from "seen" in such
a case. The output of the above "git log" talks about a "jch" branch,
which is an early part of the "seen" branch; that branch contains all
topics that are in "next" and a bit more (but not all of "seen") and
is used by the maintainer for his daily work.
are currently in flight. The output of the above "git log" talks
about a "jch" branch, which is an early part of the "seen" branch;
that branch contains all topics that are in "next" and a bit more (but
not all of "seen") and is used by the maintainer for his daily work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from