git/Documentation/SubmittingPatches, branch jch

Merge branch 'jc/doc-wholesale-replace-before-next'

2026-03-19T16:54:56Z

Doc update. * jc/doc-wholesale-replace-before-next: SubmittingPatches: spell out "replace fully to pretend to be perfect"

SubmittingPatches: spell out "replace fully to pretend to be perfect"

2026-03-09T23:25:05Z

It unfortunately is a recurring theme that new developers tend to pile more "fixup" patches on top of the already reviewed patches, making the topic longer and keeping the history of all wrong turns, which interests nobody in the larger picture. Even picking a narrow search in the list archive for "pretend to be a perfect " substring, we find these: https://lore.kernel.org/git/xmqqk29bsz2o.fsf@gitster.mtv.corp.google.com/ https://lore.kernel.org/git/xmqqd0ds5ysq.fsf@gitster-ct.c.googlers.com/ https://lore.kernel.org/git/xmqqr173faez.fsf@gitster.g/ The SubmittingPatches guide does talk about going incremental once a topic hits the 'next' branch, but it does not say much about how a new iteration of the topic should be prepared before that happens, and it does not mention that the developers are encouraged to seize the opportunity to pretend to be perfect with a full replacement set of patches. Add a new paragraph to stress this point in the section that describes the life-cycle of a patch series. Signed-off-by: Junio C Hamano

Documentation: extend guidance for submitting patches

2026-03-06T22:27:05Z

Before submitting patches on the mailing list, it is often a good idea to check for previous related discussions or if similar work is already in progress. This enables better coordination amongst contributors and could avoid duplicating work. Additionally, it is often recommended to give reviewers some time to reply to a patch series before sending new versions. This helps collect broader feedback and reduces unnecessary churn from rapid rerolls. Document this guidance in "Documentation/SubmittingPatches" accordingly. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

Merge branch 'cc/doc-submitting-patches-with-ai'

2025-11-04T15:48:06Z

AI guidelines. * cc/doc-submitting-patches-with-ai: SubmittingPatches: add section about AI

SubmittingPatches: guidance for multi-series efforts

2025-10-07T22:19:24Z

Occasionally there are efforts to contribute to the Git project that span more than one patch series in order to achieve a broader goal. By convention, the maintainer has typically suffixed the topic names with "-part-one", or "-part-1" and so on. Document that convention and suggest some guidance on how to structure proposed topic names for multi-series efforts. Suggested-by: Junio C Hamano Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

SubmittingPatches: extend release-notes experiment to topic names

2025-10-07T22:19:24Z

In d255105c99 (SubmittingPatches: release-notes entry experiment, 2024-03-25), we began an experiment to have contributors suggest a topic description to appear in our RelNotes and "What's cooking?" reports. Extend that experiment to also welcome suggested topic branch names in addition to descriptions. Suggested-by: Junio C Hamano Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

SubmittingPatches: add section about AI

2025-10-01T21:27:04Z

As more and more developer tools use AI, we are facing two main risks related to AI generated content: - its situation regarding copyright and license is not clear, and: - more and more bad quality content could be submitted for review to the mailing list. To mitigate both risks, let's add an "Use of Artificial Intelligence" section to "Documentation/SubmittingPatches" with the goal of discouraging its blind use to generate content that is submitted to the project, while still allowing us to benefit from its help in some innovative, useful and less risky ways. Helped-by: Rick Sanders Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

SubmittingPatches: allow non-real name contributions

2025-07-16T14:35:45Z

Our submission guidelines require people to use their real name, but this is not always suitable for various reasons. For people who are transgender or non-binary and are transitioning or who think they might want to transition, it can be a major obstacle and cause major discomfort to require the use of their real name. This is made worse by the fact that Git provides no way to change names built into history, so the use of a deadname is forever. Our code of conduct states that we "pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community," and changing this policy is one way we can improve things for contributors. In addition, there are some developers who are so widely known pseudonymously that they have a Wikipedia page with their handle and no real name. It would seem silly to reject patches from people who are known and respected in their open-source community just because they don't wish to share a real name. There are also other good reasons why people might operate pseudonymously: because they or their family members are well known and they wish to protect their privacy, because of current or past harassment or retaliation or fear of that happening in the future, or because of concerns about unwanted attention from government officials or other authority figures. As much as possible, we want to welcome contributions from anyone who is willing to participate positively in our community without having them worry about their safety or privacy. In all of these cases, we should allow people to proceed using a preferred name or pseudonymously if, in their best judgment, that's the right thing to do. State that it is common to use a real name but explicitly mention that contributors who are not comfortable doing so or prefer to operate pseudonymously or under a preferred name can proceed otherwise, provided the name is distinctive, identifying, and not misleading. For instance, using U+2060 (WORD JOINER) as one's ID would likely be distinctive but not identifying, since most people would have trouble reading it due to its zero-width nature. We prohibit identities which are misleading, since our goal is to create a community which works together with a common goal, and misleading or deceiving others is not conducive to good community or compatible with our code of conduct, nor is it compatible with making a legal assertion about the provenance of one's code. Explicitly prohibit anonymous contributions to ensure that we have some line of provenance to a known (if pseudonymous) author who might be able to respond to questions about it. Explain that this is the reason we have this policy to help contributors understand the rationale better. Use "some form of your real name" since some current contributors use shortened forms of their name or use initials, which have always been considered acceptable. This helps guide people who would be fine using their real name but have misconfigured `user.name` thinking it is intended to be a username or is used for authentication (despite our documentation to the contrary), but also allows for a variety of circumstances where the contributor would feel more comfortable not doing so. Note that this policy is the same as that of the Linux kernel[0] and the CNCF[1], as well as many smaller projects. The Linux kernel patch was Acked-by one of the Linux Foundation's lawyers, Michael Dolan, so it appears these changes have had legal review. Additionally, retain the section header ID for ease of linking across versions. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330 [1] https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'as/gitk-git-gui-repo-update'

2024-12-28T18:11:42Z

The developer documentation has been updated to give the latest info on gitk and git-gui maintainer. * as/gitk-git-gui-repo-update: Update the official repo of gitk

Update the official repo of gitk

2024-12-26T16:06:42Z

Point out: - current maintaner - contribution flow is via the mailing list Signed-off-by: Alexander Shopov Signed-off-by: Junio C Hamano