Re: pull requests

[Zach Pearson]

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 <address@hidden> 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.