[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 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. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
