Re: pull requests

[Zach Pearson <zach@zjp.codes>]

I’m pretty sure GitHub will also let you open a pull request via the command line if you want. Additionally, it emails PR threads to users that subscribe to them (initially maintainers) — so if you’ve got write access and would strongly prefer to keep your email based workflow it is known that it’s possible to keep it. 

> On Apr 16, 2020, at 10:55 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Hi Richard,
> 
> Sorry for the late reply. I'll try to make a good description.
> 
>>>> On 02.04.2020 05:39, Richard Stallman wrote:
>> [[[ 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. ]]]
>> I have never seen what a pull request is like to use.  I do not use
>> the systems which support them.  In trying to think about their
>> implications, I have to go by the descriptions people have sent me
>> in this discussion.
>> Unfortunately, the descriptions I've reaceived seen to conflict.
>> Perhaps people were describing different ways that different projects
>> or different platforms handle pull requests, but I did not know that
>> when I read them.
> 
> AFAIK, there are basically two different things that are called a "pull request".
> 
> The first is basically an email with details about the repository and the branch you want code "pulled" from. There are more details here: https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html, but this is largely irrelevant to this discussion because a) we can do this already (and don't need any help with that), b) our developers and contributors don't use this approach. So it's not what we've been discussing.
> 
> The second one (which is what we're considering) has been popularized by the proprietary code forge called GitHub. In there, users can make 'forks' of the original repository, where a fork is basically a copy of the original repository that belongs to the user's account (and its URL has the user's username in it). The said user can create a new branch, push some changesets into it, and then propose the said branch to the original repository and its developers for merging. By creating a "pull request".
> 
> It's a "thing": Github, as well as similar forges such as Gitlab, have a dedicated type of issue (*) that's called a "pull request". It has all the features of an "issue" (which generally means people can leave comments in it), as well as extra features: it shows the author, the source branch, a multi-line description that the author usually has to fill, the proposed commits, it can show the combined diff of those commits, users can leave comments associated with individual lines of that diff (and the UI displays that neatly), they can lead threaded discussions on said commits (which get semi-hidden as soon as the related code has changed), and the PR tracks the source branch closely, so as soon as the user pushes some new changes to the branch, the information in the PR updates automatically. The PR web page can show the status of the CI build for the proposed branch. The main repository's maintainers can merge the PR with just a couple of clicks with the mouse (this works best with small contributions). There are other features.
> 
> Overall, a lot of developers are used to this workflow and would never choose patch submission over email. Of course, not everybody. Some people just don't like web interfaces, for example.
> 
> (*) Issues are basically bug reports, but people can use them for discussions, support questions, and so on.