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
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"
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
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 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 "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 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
projects / thirdparty / git.git / commitdiff
