As mentioned in code google git-core (and by Charles Bailey in the comments, which points to git-scm community page):
Questions or comments for the Git community can be sent to the mailing list by using the email address [email protected]. Bug reports should be sent to this mailing list.
(mailing list archive here)
Update Q2 2020, you now have an actual git bugreport command (see at the end below)
Update 2015: the latest reference remains the Git community page, which, as smoothgrips points out in the comments, mentions:
You do not need to subscribe: you will be Cc'd in replies.
Please keep the Cc list intact when replying (use "Reply to all").
Greylisting may delay your first post for a few hours.
Note that the mail server will reject HTML messages with a "failed permanently" message, so use plain text.
The community page also points out to "How to Report Bugs Effectively"...
If you want to contribute a patch, go now to rtyley/submitgit, which helps you to follow the patch submission process:
If you create a pull request on github.com/git/git/, submitGit can send it to the mailing list for you, correctly formatting the patches.
The discussion stays where it is—on the list—but at least that initial step is a little easier.
Update 2015: Git For Windows now lives on GitHub (github.com/git-for-windows), and produces very recent releases: 2.4.2+.
Msysgit is phased out, using msys2 64-bits, and resulting in git-for-windows.github.io instead of the old and now obsolete msysgit.github.io.
The GitHub mirror repo image git/git is there, but not use for issues or pull request, unfortunately.
Update 2019: submitGit has an alternative: GitGitGadget (gitgitgadget.github.io), mentioned in Git 2.22 (Q2 2019)
See commit c3a7dd7 (12 Mar 2019) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 2d33728, 09 Apr 2019)
point pull requesters to GitGitGadget
In the contributing guide and PR template seen by people who open pull requests on GitHub, we mention the submitGit tool, which gives an alternative to figuring out the mailing list.
These days we also have the similar GitGitGadget tool, and we should make it clear that this is also an option.
We could continue to mention both tools, but it's probably better to pick one in order to avoid overwhelming the user with choice.
After all, one of the purposes here is to reduce friction for first-time or
infrequent contributors.
And there are a few reasons to prefer GGG:
submitGit seems to still have a few rough edges. E.g., it doesn't munge timestamps to help threaded mail readers handled out-of-order
delivery.- Subjectively,
GGG seems to be more commonly used on the list these days, especially by list regulars.
GGG seems to be under more active development (likely related to point 2).
So let's actually swap out submitGit for GGG.
While we're there, let's put another link to the GGG page in the PR template, because that's where users who are learning about it for the first time will want to go.
to read more.
With Git 2.25 (Q1 2020), there is a tutorial on object enumeration, which provides a good example on how to contribute/test/report a bug.
See commit e0479fa (11 Oct 2019) by Emily Shaffer (nasamuffin).
(Merged by Junio C Hamano -- gitster -- in commit 15d9f3d, 10 Nov 2019)
documentation: add tutorial for object walking
Signed-off-by: Emily Shaffer
Helped-by: Eric Sunshine
Existing documentation on object walks seems to be primarily intended as a reference for those already familiar with the procedure.
This tutorial attempts to give an entry-level guide to a couple of bare-bones object walks so that new Git contributors can learn the concepts without having to wade through options parsing or special casing.
The target audience is a Git contributor who is just getting started with the concept of object walking.
The goal is to prepare this contributor to be able to understand and modify existing commands which perform revision walks more easily, although it will also prepare contributors to create new commands which perform walks.
The tutorial covers a basic overview of the structs involved during object walk, setting up a basic commit walk, setting up a basic all-object walk, and adding some configuration changes to both walk types.
It intentionally does not cover how to create new commands or search for options from the command line or gitconfigs.
There is an associated patchset at https://github.com/nasamuffin/git/tree/revwalk that contains a reference implementation of the code generated by this tutorial.
Note: that tutorial has been amended in Git 2.27 (Q2 2020):
See commit e3f53ce (28 Mar 2020) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 7780604, 22 Apr 2020)
MyFirstObjectWalk: remove unnecessary conditional statement
Signed-off-by: Johannes Schindelin
Reviewed-by: Emily Shaffer
In the given example, commit cannot be NULL (because this is the loop condition: if it was NULL, the loop body would not be entered at all). It took this developer a moment or two to see that this is therefore dead code.
Let's remove it, to avoid puzzling future readers.
With Git 2.25 (Q1 2020), GitGitGadget is documented.
See commit 3c8d754, commit 3ada78d, commit 4ed5562 (31 Oct 2019) by Emily Shaffer (nasamuffin).
(Merged by Junio C Hamano -- gitster -- in commit f089ddd, 01 Dec 2019)
myfirstcontrib: hint to find gitgitgadget allower
Signed-off-by: Emily Shaffer
GitGitGadget, a handy tool for converting pull requests against Git into Git-mailing-list-friendly-patch-emails, requires as anti-spam that all new users be "/allow"ed by an existing user once before it will do anything for that new user.
While this tutorial explained that mechanism, it did not give much hint on how to go about finding someone to allow your new pull request.
So, teach our new GitGitGadget user where to look for someone who can add their name to the list.
The advice in this patch is based on the advice proposed for GitGitGadget: gitgitgadget/gitgitgadget PR 138
With Git 2.25 (Q1 2020), there are documentation updates for the mailing list archiving and nntp service.
See commit 3eae30e, commit 46c6749 (27 Nov 2019) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in <a href="https://github.com/git/git/commit/3b3d9ea6a8fbf36a8710b855062c685d9a7d33e3" rel=
