[llvm-dev] Enable Contributions Through Pull-request For LLVM
Nicolai Hähnle via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 13 12:25:50 PST 2019
On Tue, Nov 12, 2019 at 9:37 PM Syed Ahmed via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> For mutiple PRs, we have been using stacked PRs in the PyTorch repository. Edward Yang wrote a tool for this called ghstack (https://github.com/ezyang/ghstack) and my experience using it has been pleasant - you put your patches as seperate commits on top of the master and call ghstack, and ghstack separates out the commits into multiple PRs. This does require the contributer to have permissions to create branches (we do that by creating a team in the github project). The branches get created with a prefix ghstack/<contributor-name>/*. After a PR is merged, stale branches are deleted using a script by a maintainer. You can see an example stacked PR here: https://github.com/pytorch/pytorch/pull/21364.
This looks surprisingly usable. It's sad that people need to jump
through such hoops to make the workflow that Git was originally
designed for feasible on GitHub, but hey, it's something!
A couple of questions:
1. I see a bunch of `Update on "Blah"` commits on those pull requests.
I assume that ghstack automatically and transparently creates those?
2. Where does the "Resubmit of #20886" come from? Does that happen
when you rebase? Some other condition?
3. How are changes to the commit message itself reflected in the pull requests?
4. How does the final submit work? It appears that the vanilla GitHub
machinery would fail because the pull requests are not actually set up
as pull requests against master. It seems PyTorch is running some bot
for that, is that an easily reproducible setup? Of course, the
original submitter could just push the original commits in the usual
vanilla way (e.g., via the CLI), but then how do the pull requests get
closed?
5. Is there a convenient way to get at the actual underlying commits,
so that a reviewer can look at them without the ghstack branching if
so desired? It seems this should be possible via the */orig branches?
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
More information about the llvm-dev
mailing list