{"thread":{"id":"66437","subject":"A note from the maintainer","startedAt":"2026-10-01T21:29:33Z","lastAt":"2026-10-01T21:29:33Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"553869","messageId":"xmqqbj9d3y9x.fsf@gitster.g","threadId":"66437","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-01T21:29:30Z","receivedAt":"2026-10-01T21:29:33Z","isPatch":false,"body":"Welcome to the Git development community.\n\nThis message is written by the maintainer and talks about how Git\nproject is managed, and how you can work with it.\n\n\tNote.  The section on integration branches has been heavily\n\trewritten in this edition; this is partly in preparation for\n\ta medium version bump.\n\nThe current maintainer is Junio C Hamano <gitster@pobox.com>.  Spam\nfilters learned that legitimate messages come to this address only\nfrom a very few sender addresses that are known to be good, and all\nother messages are likely to be spam unless they are also sent to the\nmailing list at the same time (i.e. \"Reply-all\" to the list message\nwould reach the mailbox, but \"Reply\" will likely be thrown into the\nspam folder), so please do not send a message to this address unless\nit is also sent to the mailing list as well.\n\n\n* Mailing list and the community\n\nThe development is primarily done on the Git mailing list. Help\nrequests, feature proposals, bug reports and patches should be sent to\nthe list address <git@vger.kernel.org>.  You don't have to be\nsubscribed to send messages.  The convention on the list is to keep\neverybody involved on Cc:, so it is unnecessary to say \"Please Cc: me,\nI am not subscribed\".\n\nAs an anti-spam measure, the mailing list software may reject messages\nthat are not text/plain and drops them on the floor.  If you are a\nGMail user, you'd want to make sure \"Plain text mode\" is checked.\n\nThe mailing list, while welcoming non code contributions like bug\nreports, mostly discusses updating contents of the source tree to the\n(core) Git software, including documentation \"git help\" gives.\nNon-code contributions may have places other than the mailing list\nthat are more preferrable.  See the \"other places\" section near the\nend.\n\nBefore sending patches, please read Documentation/SubmittingPatches\nand Documentation/CodingGuidelines to familiarize yourself with the\nproject convention.\n\nIf you sent a patch and you did not hear any response from anybody for\nseveral days, it does not necessarily mean that your patch was totally\nuninteresting; it may merely mean that it was lost in the noise.\nPlease do not hesitate to send a reminder message in such a case.\nMessages getting lost in the noise may be a sign that those who can\nevaluate your patch don't have enough mental/time bandwidth to process\nthem right at the moment, and it often helps to wait until the list\ntraffic becomes calmer before sending such a reminder.\n\nThe list archive is available at a few public sites:\n\n        https://lore.kernel.org/git/\n        https://marc.info/?l=git\n        https://www.spinics.net/lists/git/\n\nFor those who prefer to read it over NNTP:\n\n\tnntp://nntp.lore.kernel.org/org.kernel.vger.git\n        nntp://news.public-inbox.org/inbox.comp.version-control.git\n\tnntp://news.gmane.io/gmane.comp.version-control.git\n\nare available.\n\nWhen you point at a message in a mailing list archive, using its\nmessage ID is often the most robust (if not very friendly) way to do\nso, like this:\n\n\thttps://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org\n\nOften these web interfaces accept the message ID with enclosing <>\nstripped (like the above example to point at one of the most important\nmessage in the Git mailing list).\n\nSome members of the development community can sometimes be found on\nthe #git and #git-devel IRC channels on Libera Chat.  Their logs are\navailable at:\n\n        https://colabti.org/ircloggy/git/last\n        https://colabti.org/ircloggy/git-devel/last\n\nThere is a volunteer-run newsletter to serve our community (\"Git Rev\nNews\" https://git.github.io/rev_news/).\n\nGit is a member project of Software Freedom Conservancy, a non-profit\norganization (https://sfconservancy.org/).  To reach a committee of\nliaisons to the conservancy, contact them at <git@sfconservancy.org>.\n\nFor our expectations on the behaviour of the community participants\ntowards each other, see CODE_OF_CONDUCT.md at the top level of the source\ntree, or:\n\n    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md\n\n\n* Reporting bugs\n\nWhen you think git does not behave as you expect, please do not stop\nyour bug report with just \"git does not work\".  \"I used git in this\nway, but it did not work\" is not much better, neither is \"I used git\nin this way, and X happend, which is broken\".  It often is that git is\ncorrect to cause X happen in such a case, and it is your expectation\nthat is broken.  People would not know what other result Y you\nexpected to see instead of X, if you left it unsaid.\n\nPlease remember to always state\n\n - what you wanted to achieve;\n\n - what you did (the version of git and the command sequence to reproduce\n   the behavior);\n\n - what you saw happen (X above);\n\n - what you expected to see (Y above); and\n\n - how the last two are different.\n\nSee https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further\nhints.  Our `git bugreport` tool gives you a handy way you can use to\nmake sure you do not forget these points when filing a bug report.\n\nIf you think you found a security-sensitive issue and want to disclose\nit to us without announcing it to wider public, please contact us at\nour security mailing list <git-security@googlegroups.com>.  This is\na closed list that is limited to people who need to know early about\nvulnerabilities, including:\n\n  - people triaging and fixing reported vulnerabilities\n  - people operating major git hosting sites with many users\n  - people packaging and distributing git to large numbers of people\n\nwhere these issues are discussed without risk of the information\nleaking out before we're ready to make public announcements.\n\n\n* Repositories and documentation.\n\nMy public git.git repositories are (mirrored) at:\n\n  https://git.kernel.org/pub/scm/git/git.git/\n  https://kernel.googlesource.com/pub/scm/git/git\n  https://repo.or.cz/alt-git.git/\n  https://github.com/git/git/\n  https://gitlab.com/git-scm/git/\n\nThis one shows not just the main integration branches, but also\nindividual topics broken out:\n\n  https://github.com/gitster/git/\n\nA few web interfaces are found at:\n\n  https://git.kernel.org/pub/scm/git/git.git\n  https://kernel.googlesource.com/pub/scm/git/git\n  https://repo.or.cz/w/alt-git.git\n\nPreformatted documentation from the tip of the \"master\" branch can be\nfound in:\n\n  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/\n  https://repo.or.cz/git-{htmldocs,manpages}.git/\n  https://github.com/gitster/git-{htmldocs,manpages}.git/\n\nThe manual pages formatted in HTML for the tip of \"master\" can be\nviewed online at:\n\n  https://git.github.io/htmldocs/git.html\n\n\n* How various branches are used.\n\nThere are four integration branches in the git.git repository that\ntrack the source tree of Git: 'master', 'maint', 'next', and 'seen'.\nCommits are almost never made directly to them.  Instead, after review\non the mailing list, each new feature or bugfix is applied to its own\ntopic branch forked from 'master' or 'maint' (or an older base when\nfixing an earlier bug), and kept out of 'master' while it is tested.\nThe quality of topic branches is judged primarily by list discussions.\n\nThe 'master' branch holds well-tested changes ready for production and\naims to be more stable than any released version.  Feature releases\nare cut from its tip and named with two-dotted decimal digits (e.g.,\nGit 2.56, tagged 'v2.56.0', made on September 28, 2026).\n\nWhenever a feature release is made, 'maint' is forked from 'master'.\nObvious, safe bugfixes for the latest feature release (and occasional\ndeveloper aids such as CI updates, but almost never new features) are\nmerged into it to cut maintenance releases named by incrementing the\nthird digit (e.g., '2.47.1' for the '2.47' series).  Bugfix topics are\nusually merged into 'master' before 'maint' to avoid last-minute\nissues, though embargoed security fixes may appear in both at the same\ntime.  'maint' is merged up into 'master', primarily to propagate\nrelease notes forward.\n\nTopic branches in good shape are merged into 'next', where new and\nexciting things take place.  'next' generally contains the tip of\n'master' and is expected to work without major breakage while topics\nin it are polished to perfection before graduating to 'master'.  Being\nin 'next' is no guarantee of appearing in any release: flawed commits\nor whole topics may be reverted from 'next' (or even from 'master' if\na regression is found late).  Because a bug may manifest only in your\nunique workflow, please help by building and using 'next' for your\ndaily work and reporting problems to the mailing list before they\nreach 'master'.\n\nThe 'seen' branch bundles the remaining topics that the maintainer has\nseen and found potentially interesting; please do not read anything\nmore into a topic being in 'seen', as topics whose ideas do not pan\nout are discarded before reaching 'next', just as topics can wither on\nthe list without support.  Contributors can use 'seen' to anticipate\nconflicts with others' in-flight topics and coordinate early.  Before\nsending patches to the list (or via GitGitGadget), it is a good idea\nto test your topic in isolation and with temporary merges to 'next'\nand 'seen'.\n\nYou can run 'git log --oneline --first-parent master..seen' to see\nwhat topics are currently in flight.  Its output mentions a 'jch'\nbranch, an early part of 'seen' that contains all of 'next' and a bit\nmore, used by the maintainer for his daily work.\n\n'master' and 'maint' are never rewound, and 'next' is rebuilt from the\ntip of 'master' only after a feature release (using the topics that\ndid not make the cut, possibly ejecting some).  Consequently, until a\ntopic is merged into 'next', updates should replace its patches with\nan improved version; once in 'next', updates must come as incremental\npatches explaining what reviewers missed and how it was corrected.\n\n\n* Other people's trees.\n\nDocumentation/SubmittingPatches outlines to whom your proposed changes\nshould be sent.  As described in contrib/README, I would delegate fixes\nand enhancements in contrib/ area to the primary contributors of them.\n\nAlthough the following are included in git.git repository, they have their\nown authoritative repository and maintainers:\n\n - git-gui/ comes from git-gui project, maintained by Johannes Sixt:\n\n        https://github.com/j6t/git-gui\n\n - gitk-git/ comes from gitk project, maintained by Johannes Sixt:\n\n        https://github.com/j6t/gitk\n\n - po/ comes from the localization coordinator, Jiang Xin:\n\n\thttps://github.com/git-l10n/git-po/\n\nWhen sending proposed updates and fixes to these parts of the system,\nplease base your patches on these trees, not git.git (the former two\neven have different directory structures).\n\n\n* Other places.\n\nAs the Git ecosystem has grown larger over the years, there are\ndocumentation sites and third-party tools that have been created and\nmaintained by friendly third-parties.  Reporting issues with them to\nthe main mailing list is still welcomed by the list participants, but\nmost likely you will be asked to contact these third-parties directly.\n\n - git-scm website (https://www.git-scm.com/) is maintained directly\n   on its GitHub repository and its issues are managed there.\n\n   https://github.com/git/git-scm.com/issues\n   https://github.com/git/git-scm.com/?tab=readme-ov-file#contributing\n\n - Git for Windows (https://gitforwindows.org/) is a project that\n   packages (core) Git software with some other goodies for the\n   Windows platform.  They manage their own issues list and their\n   changes are managed directly on GitHub via pull requests, focused\n   primarily on Windows specific issues and their additions (like\n   Windows installer).\n\n   https://github.com/git-for-windows/git/wiki/How-to-participate\n   https://github.com/git-for-windows/git/issues\n\n - The online edition of ProGit Book hosted at git-scm.com/book/ is\n   managed by the Pro Git book folks, and they maintain their work and\n   issues at their GitHub repository.\n\n   https://github.com/progit/progit2/issues\n   https://github.com/progit/progit2/blob/main/CONTRIBUTING.md\n"}]}