MaintNotes - git - Git at Google

 To: git@vger.kernel.org
 Subject: A note from the maintainer

 Welcome to the Git development community.

 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 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
 spam folder), so please do not send a message to this address unless
 it is also sent to the mailing list as well.


 * Mailing list and the community

 The development is primarily done on the Git mailing list. Help
 requests, feature proposals, bug reports and patches should be sent to
 the list address <git@vger.kernel.org>.  You don't have to be
 subscribed to send messages.  The convention on the list is to keep
 everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
 I am not subscribed".

 As an anti-spam measure, the mailing list software may reject messages
 that are not text/plain and drops them on the floor.  If you are a
 GMail user, you'd want to make sure "Plain text mode" is checked.

 The mailing list, while welcoming non code contributions like bug
 reports, mostly discusses updating contents of the source tree to the
 (core) Git software, including documentation "git help" gives.
 Non-code contributions may have places other than the mailing list
 that are more preferrable.  See the "other places" section near the
 end.

 Before sending patches, please read Documentation/SubmittingPatches
 and Documentation/CodingGuidelines to familiarize yourself with the
 project convention.

 If you sent a patch and you did not hear any response from anybody for
 several days, it does not necessarily mean that your patch was totally
 uninteresting; it may merely mean that it was lost in the noise.
 Please do not hesitate to send a reminder message in such a case.
 Messages getting lost in the noise may be a sign that those who can
 evaluate your patch don't have enough mental/time bandwidth to process
 them right at the moment, and it often helps to wait until the list
 traffic becomes calmer before sending such a reminder.

 The list archive is available at a few public sites:

         https://lore.kernel.org/git/
         https://marc.info/?l=git
         https://www.spinics.net/lists/git/

 For those who prefer to read it over NNTP:

 	nntp://nntp.lore.kernel.org/org.kernel.vger.git
         nntp://news.public-inbox.org/inbox.comp.version-control.git
 	nntp://news.gmane.io/gmane.comp.version-control.git

 are available.

 When you point at a message in a mailing list archive, using its
 message ID is often the most robust (if not very friendly) way to do
 so, like this:

 	https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

 Often these web interfaces accept the message ID with enclosing <>
 stripped (like the above example to point at one of the most important
 message in the Git mailing list).

 Some members of the development community can sometimes be found on
 the #git and #git-devel IRC channels on Libera Chat.  Their logs are
 available at:

         https://colabti.org/ircloggy/git/last
         https://colabti.org/ircloggy/git-devel/last

 There is a volunteer-run newsletter to serve our community ("Git Rev
 News" https://git.github.io/rev_news/).

 Git is a member project of Software Freedom Conservancy, a non-profit
 organization (https://sfconservancy.org/).  To reach a committee of
 liaisons to the conservancy, contact them at <git@sfconservancy.org>.

 For our expectations on the behaviour of the community participants
 towards each other, see CODE_OF_CONDUCT.md at the top level of the source
 tree, or:

     https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


 * Reporting bugs

 When you think git does not behave as you expect, please do not stop
 your bug report with just "git does not work".  "I used git in this
 way, but it did not work" is not much better, neither is "I used git
 in this way, and X happend, which is broken".  It often is that git is
 correct to cause X happen in such a case, and it is your expectation
 that is broken.  People would not know what other result Y you
 expected to see instead of X, if you left it unsaid.

 Please remember to always state

  - what you wanted to achieve;

  - what you did (the version of git and the command sequence to reproduce
    the behavior);

  - what you saw happen (X above);

  - what you expected to see (Y above); and

  - how the last two are different.

 See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
 hints.  Our `git bugreport` tool gives you a handy way you can use to
 make sure you do not forget these points when filing a bug report.

 If you think you found a security-sensitive issue and want to disclose
 it to us without announcing it to wider public, please contact us at
 our security mailing list <git-security@googlegroups.com>.  This is
 a closed list that is limited to people who need to know early about
 vulnerabilities, including:

   - people triaging and fixing reported vulnerabilities
   - people operating major git hosting sites with many users
   - people packaging and distributing git to large numbers of people

 where these issues are discussed without risk of the information
 leaking out before we're ready to make public announcements.


 * Repositories and documentation.

 My public git.git repositories are (mirrored) at:

   https://git.kernel.org/pub/scm/git/git.git/
   https://kernel.googlesource.com/pub/scm/git/git
   https://repo.or.cz/alt-git.git/
   https://github.com/git/git/
   https://gitlab.com/git-scm/git/

 This one shows not just the main integration branches, but also
 individual topics broken out:

   https://github.com/gitster/git/

 A few web interfaces are found at:

   https://git.kernel.org/pub/scm/git/git.git
   https://kernel.googlesource.com/pub/scm/git/git
   https://repo.or.cz/w/alt-git.git

 Preformatted documentation from the tip of the "master" branch can be
 found in:

   https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
   https://repo.or.cz/git-{htmldocs,manpages}.git/
   https://github.com/gitster/git-{htmldocs,manpages}.git/

 The manual pages formatted in HTML for the tip of "master" can be
 viewed online at:

   https://git.github.io/htmldocs/git.html


 * How various branches are used.

 There are four integration branches in the git.git repository that
 track the source tree of Git: 'master', 'maint', 'next', and 'seen'.
 Commits are almost never made directly to them.  Instead, after review
 on the mailing list, each new feature or bugfix is applied to its own
 topic branch forked from 'master' or 'maint' (or an older base when
 fixing an earlier bug), and kept out of 'master' while it is tested.
 The quality of topic branches is judged primarily by list discussions.

 The 'master' branch holds well-tested changes ready for production and
 aims to be more stable than any released version.  Feature releases
 are cut from its tip and named with two-dotted decimal digits (e.g.,
 Git 2.56, tagged 'v2.56.0', made on September 28, 2026).

 Whenever a feature release is made, 'maint' is forked from 'master'.
 Obvious, safe bugfixes for the latest feature release (and occasional
 developer aids such as CI updates, but almost never new features) are
 merged into it to cut maintenance releases named by incrementing the
 third digit (e.g., '2.47.1' for the '2.47' series).  Bugfix topics are
 usually merged into 'master' before 'maint' to avoid last-minute
 issues, though embargoed security fixes may appear in both at the same
 time.  'maint' is merged up into 'master', primarily to propagate
 release notes forward.

 Topic branches in good shape are merged into 'next', where new and
 exciting things take place.  'next' generally contains the tip of
 'master' and is expected to work without major breakage while topics
 in it are polished to perfection before graduating to 'master'.  Being
 in 'next' is no guarantee of appearing in any release: flawed commits
 or whole topics may be reverted from 'next' (or even from 'master' if
 a regression is found late).  Because a bug may manifest only in your
 unique workflow, please help by building and using 'next' for your
 daily work and reporting problems to the mailing list before they
 reach 'master'.

 The 'seen' branch bundles the remaining topics that the maintainer has
 seen and found potentially interesting; please do not read anything
 more into a topic being in 'seen', as topics whose ideas do not pan
 out are discarded before reaching 'next', just as topics can wither on
 the list without support.  Contributors can use 'seen' to anticipate
 conflicts with others' in-flight topics and coordinate early.  Before
 sending patches to the list (or via GitGitGadget), it is a good idea
 to test your topic in isolation and with temporary merges to 'next'
 and 'seen'.

 You can run 'git log --oneline --first-parent master..seen' to see
 what topics are currently in flight.  Its output mentions a 'jch'
 branch, an early part of 'seen' that contains all of 'next' and a bit
 more, used by the maintainer for his daily work.

 'master' and 'maint' are never rewound, and 'next' is rebuilt from the
 tip of 'master' only after a feature release (using the topics that
 did not make the cut, possibly ejecting some).  Consequently, until a
 topic is merged into 'next', updates should replace its patches with
 an improved version; once in 'next', updates must come as incremental
 patches explaining what reviewers missed and how it was corrected.


 * Other people's trees.

 Documentation/SubmittingPatches outlines to whom your proposed changes
 should be sent.  As described in contrib/README, I would delegate fixes
 and enhancements in contrib/ area to the primary contributors of them.

 Although the following are included in git.git repository, they have their
 own authoritative repository and maintainers:

  - git-gui/ comes from git-gui project, maintained by Johannes Sixt:

         https://github.com/j6t/git-gui

  - gitk-git/ comes from gitk project, maintained by Johannes Sixt:

         https://github.com/j6t/gitk

  - po/ comes from the localization coordinator, Jiang Xin:

 	https://github.com/git-l10n/git-po/

 When sending proposed updates and fixes to these parts of the system,
 please base your patches on these trees, not git.git (the former two
 even have different directory structures).


 * Other places.

 As the Git ecosystem has grown larger over the years, there are
 documentation sites and third-party tools that have been created and
 maintained by friendly third-parties.  Reporting issues with them to
 the main mailing list is still welcomed by the list participants, but
 most likely you will be asked to contact these third-parties directly.

  - git-scm website (https://www.git-scm.com/) is maintained directly
    on its GitHub repository and its issues are managed there.

    https://github.com/git/git-scm.com/issues
    https://github.com/git/git-scm.com/?tab=readme-ov-file#contributing

  - Git for Windows (https://gitforwindows.org/) is a project that
    packages (core) Git software with some other goodies for the
    Windows platform.  They manage their own issues list and their
    changes are managed directly on GitHub via pull requests, focused
    primarily on Windows specific issues and their additions (like
    Windows installer).

    https://github.com/git-for-windows/git/wiki/How-to-participate
    https://github.com/git-for-windows/git/issues

  - The online edition of ProGit Book hosted at git-scm.com/book/ is
    managed by the Pro Git book folks, and they maintain their work and
    issues at their GitHub repository.

    https://github.com/progit/progit2/issues
    https://github.com/progit/progit2/blob/main/CONTRIBUTING.md
	To: git@vger.kernel.org
	Subject: A note from the maintainer

	Welcome to the Git development community.

	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 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
	spam folder), so please do not send a message to this address unless
	it is also sent to the mailing list as well.


	* Mailing list and the community

	The development is primarily done on the Git mailing list. Help
	requests, feature proposals, bug reports and patches should be sent to
	the list address <git@vger.kernel.org>. You don't have to be
	subscribed to send messages. The convention on the list is to keep
	everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
	I am not subscribed".

	As an anti-spam measure, the mailing list software may reject messages
	that are not text/plain and drops them on the floor. If you are a
	GMail user, you'd want to make sure "Plain text mode" is checked.

	The mailing list, while welcoming non code contributions like bug
	reports, mostly discusses updating contents of the source tree to the
	(core) Git software, including documentation "git help" gives.
	Non-code contributions may have places other than the mailing list
	that are more preferrable. See the "other places" section near the
	end.

	Before sending patches, please read Documentation/SubmittingPatches
	and Documentation/CodingGuidelines to familiarize yourself with the
	project convention.

	If you sent a patch and you did not hear any response from anybody for
	several days, it does not necessarily mean that your patch was totally
	uninteresting; it may merely mean that it was lost in the noise.
	Please do not hesitate to send a reminder message in such a case.
	Messages getting lost in the noise may be a sign that those who can
	evaluate your patch don't have enough mental/time bandwidth to process
	them right at the moment, and it often helps to wait until the list
	traffic becomes calmer before sending such a reminder.

	The list archive is available at a few public sites:

	https://lore.kernel.org/git/
	https://marc.info/?l=git
	https://www.spinics.net/lists/git/

	For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

	are available.

	When you point at a message in a mailing list archive, using its
	message ID is often the most robust (if not very friendly) way to do
	so, like this:

	https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

	Often these web interfaces accept the message ID with enclosing <>
	stripped (like the above example to point at one of the most important
	message in the Git mailing list).

	Some members of the development community can sometimes be found on
	the #git and #git-devel IRC channels on Libera Chat. Their logs are
	available at:

	https://colabti.org/ircloggy/git/last
	https://colabti.org/ircloggy/git-devel/last

	There is a volunteer-run newsletter to serve our community ("Git Rev
	News" https://git.github.io/rev_news/).

	Git is a member project of Software Freedom Conservancy, a non-profit
	organization (https://sfconservancy.org/). To reach a committee of
	liaisons to the conservancy, contact them at <git@sfconservancy.org>.

	For our expectations on the behaviour of the community participants
	towards each other, see CODE_OF_CONDUCT.md at the top level of the source
	tree, or:

	https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


	* Reporting bugs

	When you think git does not behave as you expect, please do not stop
	your bug report with just "git does not work". "I used git in this
	way, but it did not work" is not much better, neither is "I used git
	in this way, and X happend, which is broken". It often is that git is
	correct to cause X happen in such a case, and it is your expectation
	that is broken. People would not know what other result Y you
	expected to see instead of X, if you left it unsaid.

	Please remember to always state

	- what you wanted to achieve;

	- what you did (the version of git and the command sequence to reproduce
	the behavior);

	- what you saw happen (X above);

	- what you expected to see (Y above); and

	- how the last two are different.

	See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
	hints. Our `git bugreport` tool gives you a handy way you can use to
	make sure you do not forget these points when filing a bug report.

	If you think you found a security-sensitive issue and want to disclose
	it to us without announcing it to wider public, please contact us at
	our security mailing list <git-security@googlegroups.com>. This is
	a closed list that is limited to people who need to know early about
	vulnerabilities, including:

	- people triaging and fixing reported vulnerabilities
	- people operating major git hosting sites with many users
	- people packaging and distributing git to large numbers of people

	where these issues are discussed without risk of the information
	leaking out before we're ready to make public announcements.


	* Repositories and documentation.

	My public git.git repositories are (mirrored) at:

	https://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	https://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://gitlab.com/git-scm/git/

	This one shows not just the main integration branches, but also
	individual topics broken out:

	https://github.com/gitster/git/

	A few web interfaces are found at:

	https://git.kernel.org/pub/scm/git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
	https://repo.or.cz/w/alt-git.git

	Preformatted documentation from the tip of the "master" branch can be
	found in:

	https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
	https://repo.or.cz/git-{htmldocs,manpages}.git/
	https://github.com/gitster/git-{htmldocs,manpages}.git/

	The manual pages formatted in HTML for the tip of "master" can be
	viewed online at:

	https://git.github.io/htmldocs/git.html


	* How various branches are used.

	There are four integration branches in the git.git repository that
	track the source tree of Git: 'master', 'maint', 'next', and 'seen'.
	Commits are almost never made directly to them. Instead, after review
	on the mailing list, each new feature or bugfix is applied to its own
	topic branch forked from 'master' or 'maint' (or an older base when
	fixing an earlier bug), and kept out of 'master' while it is tested.
	The quality of topic branches is judged primarily by list discussions.

	The 'master' branch holds well-tested changes ready for production and
	aims to be more stable than any released version. Feature releases
	are cut from its tip and named with two-dotted decimal digits (e.g.,
	Git 2.56, tagged 'v2.56.0', made on September 28, 2026).

	Whenever a feature release is made, 'maint' is forked from 'master'.
	Obvious, safe bugfixes for the latest feature release (and occasional
	developer aids such as CI updates, but almost never new features) are
	merged into it to cut maintenance releases named by incrementing the
	third digit (e.g., '2.47.1' for the '2.47' series). Bugfix topics are
	usually merged into 'master' before 'maint' to avoid last-minute
	issues, though embargoed security fixes may appear in both at the same
	time. 'maint' is merged up into 'master', primarily to propagate
	release notes forward.

	Topic branches in good shape are merged into 'next', where new and
	exciting things take place. 'next' generally contains the tip of
	'master' and is expected to work without major breakage while topics
	in it are polished to perfection before graduating to 'master'. Being
	in 'next' is no guarantee of appearing in any release: flawed commits
	or whole topics may be reverted from 'next' (or even from 'master' if
	a regression is found late). Because a bug may manifest only in your
	unique workflow, please help by building and using 'next' for your
	daily work and reporting problems to the mailing list before they
	reach 'master'.

	The 'seen' branch bundles the remaining topics that the maintainer has
	seen and found potentially interesting; please do not read anything
	more into a topic being in 'seen', as topics whose ideas do not pan
	out are discarded before reaching 'next', just as topics can wither on
	the list without support. Contributors can use 'seen' to anticipate
	conflicts with others' in-flight topics and coordinate early. Before
	sending patches to the list (or via GitGitGadget), it is a good idea
	to test your topic in isolation and with temporary merges to 'next'
	and 'seen'.

	You can run 'git log --oneline --first-parent master..seen' to see
	what topics are currently in flight. Its output mentions a 'jch'
	branch, an early part of 'seen' that contains all of 'next' and a bit
	more, used by the maintainer for his daily work.

	'master' and 'maint' are never rewound, and 'next' is rebuilt from the
	tip of 'master' only after a feature release (using the topics that
	did not make the cut, possibly ejecting some). Consequently, until a
	topic is merged into 'next', updates should replace its patches with
	an improved version; once in 'next', updates must come as incremental
	patches explaining what reviewers missed and how it was corrected.


	* Other people's trees.

	Documentation/SubmittingPatches outlines to whom your proposed changes
	should be sent. As described in contrib/README, I would delegate fixes
	and enhancements in contrib/ area to the primary contributors of them.

	Although the following are included in git.git repository, they have their
	own authoritative repository and maintainers:

	- git-gui/ comes from git-gui project, maintained by Johannes Sixt:

	https://github.com/j6t/git-gui

	- gitk-git/ comes from gitk project, maintained by Johannes Sixt:

	https://github.com/j6t/gitk

	- po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

	When sending proposed updates and fixes to these parts of the system,
	please base your patches on these trees, not git.git (the former two
	even have different directory structures).


	* Other places.

	As the Git ecosystem has grown larger over the years, there are
	documentation sites and third-party tools that have been created and
	maintained by friendly third-parties. Reporting issues with them to
	the main mailing list is still welcomed by the list participants, but
	most likely you will be asked to contact these third-parties directly.

	- git-scm website (https://www.git-scm.com/) is maintained directly
	on its GitHub repository and its issues are managed there.

	https://github.com/git/git-scm.com/issues
	https://github.com/git/git-scm.com/?tab=readme-ov-file#contributing

	- Git for Windows (https://gitforwindows.org/) is a project that
	packages (core) Git software with some other goodies for the
	Windows platform. They manage their own issues list and their
	changes are managed directly on GitHub via pull requests, focused
	primarily on Windows specific issues and their additions (like
	Windows installer).

	https://github.com/git-for-windows/git/wiki/How-to-participate
	https://github.com/git-for-windows/git/issues

	- The online edition of ProGit Book hosted at git-scm.com/book/ is
	managed by the Pro Git book folks, and they maintain their work and
	issues at their GitHub repository.

	https://github.com/progit/progit2/issues
	https://github.com/progit/progit2/blob/main/CONTRIBUTING.md