{"thread":{"id":"59388","subject":"A note from the maintainer","startedAt":"2023-03-13T18:02:48Z","lastAt":"2023-03-13T18:02:48Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"473466","messageId":"xmqqa60gv8ap.fsf@gitster.g","threadId":"59388","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-13T18:02:38Z","receivedAt":"2023-03-13T18:02:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"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\nThe current maintainer is Junio C Hamano <gitster@pobox.com>; please\ndo not send any message to this address unless it also goes to the\nmailing list, because it is likely that such a message will not be\nseen by any human being.  Spam filters learned that legitimate\nmessages to the address come only from a very few sender addresses\nthat are known to be good, and messages from all others are likely to\nbe spam unless they are also sent to the mailing list at the same time\n(i.e. \"Reply-all\" to the list message would reach the mailbox, but\n\"Reply\" will likely be thrown into the spam folder).\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 rejects 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\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 could be that your patch was totally uninteresting,\nbut it also is possible that it was simply lost in the noise.  Please\ndo not hesitate to send a reminder message in such a case.  Messages\ngetting lost in the noise may be a sign that those who can evaluate\nyour patch don't have enough mental/time bandwidth to process them\nright at the moment, and it often helps to wait until the list traffic\nbecomes calmer before sending such a reminder.\n\nThe list archive is available at a few public sites:\n\n        http://lore.kernel.org/git/\n        http://marc.info/?l=git\n        http://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\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\thttp://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 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        http://colabti.org/irclogger/irclogger_log/git\n        http://colabti.org/irclogger/irclogger_log/git-devel\n\nThere is a volunteer-run newsletter to serve our community (\"Git Rev\nNews\" http://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 expected\nto 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 http://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-vcs/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  http://git.kernel.org/pub/scm/git/git.git\n  https://kernel.googlesource.com/pub/scm/git/git\n  http://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 git.git repository that track\nthe source tree of git: \"master\", \"maint\", \"next\", and \"seen\".  They\nhowever almost never get new commits made directly on them.  Instead,\na branch is forked from either \"master\" or \"maint\" for each \"topic\",\nwhether it is a new feature or fix for a bug, and holds a set of\ncommits that belong to the same theme, and then such a \"topic branch\"\nis merged to these integration branches.\n\nThe \"master\" branch is meant to contain what are very well tested and\nready to be used in a production setting.  Every now and then, a\n\"feature release\" is cut from the tip of this branch.  They used to be\nnamed with three dotted decimal digits (e.g. \"1.8.5\"), but we have\nswitched the versioning scheme and \"feature releases\" are named with\nthree-dotted decimal digits that ends with \".0\" (e.g. \"1.9.0\").\n\nThe last such release was 2.40 done on Mar 13rd, 2023.  You can expect\nthat the tip of the \"master\" branch is always more stable than any of\nthe released versions.\n\nWhenever a feature release is made, \"maint\" branch is forked off from\n\"master\" at that point.  Obvious and safe fixes after a feature\nrelease are merged to this branch and maintenance releases are cut\nfrom it.  Usually these fixes are merged to the \"master\" branch first,\nseveral days before merged to the \"maint\" branch, to reduce the chance\nof last-minute issues, but things like embargoed security fixes may\nfirst appear in the maintenance tracks and merged up to \"master\" at\nthe same time.  The maintenance releases used to be named with\nfour dotted decimal, named after the feature release they are updates\nto (e.g. \"1.8.5.1\" was the first maintenance release for \"1.8.5\"\nfeature release).  These days, maintenance releases are named by\nincrementing the last digit of three-dotted decimal name (e.g.\n\"2.29.2\" was the second maintenance release for the \"2.29\" series).\n\nNew features never go to the \"maint\" branch.  It is merged into\n\"master\" primarily to propagate the description in the release notes\nforward.\n\nA new development does not usually happen on \"master\". When you send a\nseries of patches, after review on the mailing list, a separate topic\nbranch is forked from the tip of \"master\" (or somewhere older, especially\nwhen the topic is about fixing an earlier bug) and your patches are queued\nthere, and kept out of \"master\" while people test it out. The quality of\ntopic branches are judged primarily by the mailing list discussions.\n\nTopic branches that are in good shape are merged to the \"next\" branch. In\ngeneral, the \"next\" branch always contains the tip of \"master\".  It might\nnot be quite rock-solid, but is expected to work more or less without major\nbreakage. The \"next\" branch is where new and exciting things take place. A\ntopic that is in \"next\" is expected to be polished to perfection before it\nis merged to \"master\".  Please help this process by building & using the\n\"next\" branch for your daily work, and reporting any new bugs you find to\nthe mailing list, before the breakage is merged down to the \"master\".\n\nThe \"seen\" (formerly \"pu\", proposed updates) branch bundles all the\nremaining topic branches the maintainer happens to have seen.  There\nis no guarantee that the maintainer has enough bandwidth to pick up any\nand all topics that are remotely promising from the list traffic, so\nplease do not read too much into a topic being on (or not on) the \"seen\"\nbranch.  This branch is mainly to remind the maintainer that the topics\nin them may turn out to be interesting when they are polished, nothing\nmore, but can be used by contributors to anticipate what topics from\nothers may cause conflict with your work, and find people who are working.\non these topics to talk to before the potential conflicts get out of\ncontrol. The topics on this branch aren't usually complete, well tested,\nor well documented and they often need further work.  When a topic that\nwas in \"seen\" proves to be in a testable shape, it is merged to \"next\".\n\nYou can run \"git log --first-parent master..seen\" to see what topics are\ncurrently in flight.  Sometimes, an idea that looked promising turns out\nto be not so good and the topic can be dropped from \"seen\" in such a case.\nThe output of the above \"git log\" talks about a \"jch\" branch, which is an\nearly part of the \"seen\" branch; that branch contains all topics that\nare in \"next\" and a bit more (but not all of \"seen\") and is used by the\nmaintainer for his daily work.  Using the tip of this branch, instead of\n'next', as your daily driver is also recommended.\n\nThe two branches \"master\" and \"maint\" are never rewound, and \"next\"\nusually will not be either.  After a feature release is made from\n\"master\", however, \"next\" will be rebuilt from the tip of \"master\"\nusing the topics that didn't make the cut in the feature release.\nSome topics that used to be in \"next\" during the previous cycle may\nget ejected from \"next\" when this happens.\n\nA natural consequence of how \"next\" and \"seen\" bundles topics together\nis that until a topic is merged to \"next\", updates to it is expected\nby replacing the patch(es) in the topic with an improved version,\nand once a topic is merged to \"next\", updates to it needs to come as\nincremental patches, pointing out what was wrong in the previous\npatches and how the problem was corrected.\n\nNote that being in \"next\" is not a guarantee to appear in the next\nrelease, nor even in any future release.  There were cases that topics\nneeded reverting a few commits in them before graduating to \"master\",\nor a topic that already was in \"next\" was reverted from \"next\" because\nfatal flaws were found in it after it was merged to \"next\".\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 Pratyush Yadav:\n\n        https://github.com/prati0100/git-gui.git\n\n - gitk-git/ comes from Paul Mackerras's gitk project:\n\n        git://ozlabs.org/~paulus/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"}]}