Re: pull requests

[Alex Ott]

For GitHub there is https://hub.github.com/ - command line tool that allows
to create a new PR, pull PR into your tree to review, look into issues,
change issues, etc.  It's integrated with Emacs tools, like, Magit (via
https://github.com/vermiculus/magithub)

Github also announced recently another tool with similar functionality:
https://github.com/cli/cli, but I haven't try it.


Zach Pearson  at "Thu, 16 Apr 2020 23:24:56 -0500" wrote:
 ZP> I’m pretty sure GitHub will also let you open a pull request via the 
command line if you
 ZP> want. Additionally, it emails PR threads to users that subscribe to them 
(initially
 ZP> maintainers) — so if you’ve got write access and would strongly prefer to 
keep your email
 ZP> 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.




-- 
With best wishes,                    Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)