On Mon, Mar 17, 2025 at 00:06:33 -0400, Richard Stallman wrote: > > But github changed the > > definition of "pull request": in this workflow, you "fork" a git tree > > (make an identical copy on the github server) by clicking a few buttons > > on github's web ui, make some changes on your copy of the git branch, > > then start a pull request to the upstream by clicking a few buttons on > > github's web ui. The upstream maintainer then can accept or reject the > > changes by clicking a button. So by definition, things are done on the > > web interface. > > There are several reasons why we don't want to do this. We don't want > to have to give a savannah account to everyone that submits patches. > We don't want to redistribute their patches from savannah while we > don't have copyright assignments or while the maintainers have not > judged them. We don't want the submission of patches take up the > savannah hackers' time. > > And we don't want to pressure contributors to use a web interface. > It is fine to support one as one method, but the email method > must not be deprecated or rendered undesirable. > > Therefore, we won't do pull requests in github style. It would be ok > to support the original basic git method of pull request, as an option > alongside the email method. > > We need to distinguish these two kinds of pull requests clearly. > Are there established terms for the two? > > For now, I will call them "githubish pull requests" and "basic git > pull requests", but I'd rather use established terms if there are > acceptable ones.
But anyone using Git can already do this today. It is a decentralized VCS; that's part of its design. Savannah doesn't need to support it. # This first command can be skipped if the user has already pulled # from this repository before $ git remote add foo path/to/remote/repository # HTTPS, SSH, ... $ git fetch foo # grab branches A "pull" in Git is a fetch+merge. I didn't list it above because Git offers a number of different ways to approach this. But, for the sake of literally using the term "pull": $ git checkout foo/branch-name # foo's branch $ git pull # update with most recent changes The challenge is in conveniently making those changes available to be pulled. Most users aren't going to run their own servers. If you don't want to allow users to push to Savannah, where do their changes go? They can use a public host/forge, but then they're not using Savannah. If you want users to be able to say "I made changes, please pull from my repository", and have that be convenient to do, you need to offer them the convenience of having a place to host a repository for their changes. But if users are asking for a "pull request" or "merge request" feature, I'd expect that they're talking about UI to do so, like GitHub/GitLab (because, again, Git otherwise offers it already). Another option is to add the option to Savannah to "fork" a repo and to create a pull request, and present to them guidance on how to do so with their own host. Perhaps offer documentation for approved hosts that meet the repo criteria. -- Mike Gerwitz https://mikegerwitz.com
