git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Should we auto-close PRs on git/git?

From
Emily Shaffer <emilyshaffer@google.com>
Date
Nov 9, 2019, 02:00 UTC
Message-ID
<20191109020037.GB60198@google.com>
Hi all,

It seems to me that the friendly template text we prefill when someone opens a pull request in github.com/git/git isn't being fully appreciated by many interested contributors. For some time now, Johannes has been slogging through the list to try to narrow it down to folks who are still interested in contributing, and yesterday on #git-devel said he was pretty happy with the progress so far.

But to me, this seems like a sort of Sisyphean task - more folks will want to make contributions and not read the template text, and we will have more PRs being ignored forever, especially if Johannes decides he doesn't want to shepherd those changes anymore (I would have decided that long ago, in his shoes).

To that end, I wonder if we should add an Action to automatically close PRs on that repo. It looks like https://github.com/dessant/repo-lockdown would do the trick. We could close incoming PRs automatically with a kind, maybe more succinct or prescriptive version of the prefill text encouraging folks to open the exact same PR against gitgitgadget/git instead.

Here's the prefilled template now:
  Thanks for taking the time to contribute to Git! Please be advised
  that the Git community does not use github.com for their
  contributions. Instead, we use a mailing list (git@vger.kernel.org)
  for code submissions, code reviews, and bug reports. Nevertheless, you
  can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently
  send your Pull Requests commits to our mailing list.
  Please read the "guidelines for contributing" linked above!
Maybe we can close PRs with something like this:
  Thank you for taking the time to submit a patch!
  However, Git does not accept submissions via GitHub pull requests.
  You can open an identical pull request to this one against
  https://github.com/gitgitgadget/git and follow the instructions there
  to submit it to the Git mailing list, where reviews are performed.
  If you don't want to subscribe to the mailing list, you can keep an
  eye on your patch at https://public-inbox.org/git, or by watching
  comments on your GitGitGadget pull request.
  More info on GitGitGadget: https://gitgitgadget.github.io

I was aiming for "same message, but firmer", and "write down something so we have a place to start". I look forward to the discussion.

 - Emily
PS: Today we have 17 PRs open against git/git, and I think all of them
have been nudged by dscho in comments to open against GGG instead. Many
are in a state where dscho is sending a ping every few weeks to see if
the committer is interested in following through.
https://github.com/git/git/pulls
Next: Junio C Hamano
Message 1 of 22 in “Should we auto-close PRs on git/git?”
  1. Emily ShafferNov 9, 2019
  2. Junio C HamanoNov 9, 2019
  3. Stephen SmithNov 13, 2019
  4. Johannes SchindelinNov 12, 2019
  5. Jeff KingNov 13, 2019
  6. Johannes SchindelinNov 13, 2019
  7. Jeff KingNov 14, 2019
  8. Johannes SchindelinNov 14, 2019
  9. GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?Johannes Schindelin, Nov 18, 2019
  10. Jeff KingNov 21, 2019
  11. Johannes SchindelinNov 22, 2019
  12. Johannes SchindelinNov 22, 2019
  13. Jeff KingNov 25, 2019
  14. Johannes SchindelinNov 26, 2019
  15. Eric WongNov 26, 2019
  16. Johannes SchindelinNov 26, 2019
  17. Eric WongNov 26, 2019
  18. Johannes SchindelinNov 26, 2019
  19. Eric WongNov 26, 2019
  20. Junio C HamanoNov 27, 2019
  21. Eric WongNov 27, 2019
  22. Emily ShafferNov 13, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.