<p dir="ltr">Hi,</p>
<p dir="ltr">You can alter the content of a GitHub PR after its initial creation. The semantics of a PR is "please merge my branch named B into your repo" where the branch B is a mutable pointer to a commit.</p>
<p dir="ltr">A workflow I've used a few times is to craft a nice sequence of commits for review and, once accepted, updated the PR to a squashed version of the same. Not that I like squashing, but that's what upstream wanted.</p>
<p dir="ltr">In fact, the mutability of a PR is something you have to be a bit careful about on GitHub as you may not be accepting what you reviewed. It doesn't seem very easy to see how the branch has changed over time: there is no audit facility. I'd have thought the tooling discussed earlier should be able to take care of this problem.</p>
<p dir="ltr">Cheers,</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 28 Sep 2016 09:44, "Simon Marlow" <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Well, let's be careful here.  I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR.<br><br></div>Perhaps you could build something that would allow revisions to PRs too... that would be cool.  <br><br></div>Cheers<br></div>Simon<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 28 September 2016 at 03:22, Michael Sloan <span dir="ltr"><<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Exactly!  So we will be using Phabricator for the review process, but<br>
with the github PRs you can use plain git.  This means that new<br>
contributors will only need to learn about phabricator, and arc will<br>
be non-mandatory though probably recommended.<br>
<br>
Glad you like the idea :)<br>
<span><font color="#888888"><br>
-Michael<br>
</font></span><div><div><br>
On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>> wrote:<br>
> So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided the integration works smoothly, I quite like this idea.<br>
><br>
> Richard<br>
><br>
>> On Sep 27, 2016, at 5:32 PM, Michael Sloan <<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>> wrote:<br>
>><br>
>> You're welcome Richard!  I look forward to helping make it happen.  In<br>
>> the other thread, Alexander Vershilov mentioned that we might instead<br>
>> consider the following more straightforward workflow:<br>
>><br>
>> 0) Have a bot that watches github for PRs.<br>
>> 1) Submit whatever you want to github as a PR.<br>
>> 2) It will be automatically closed and migrated to Phabricator.  I<br>
>> would like it to automatically create a Phabricator account if you do<br>
>> not already have one.  The message from the bot will tell you about<br>
>> this action, and explain how to log in, perhaps even linking to<br>
>> resources about Phabricator.<br>
>><br>
>> Is this worth it?  I think it is for the one-off cases.  However, you<br>
>> will have to be prepared that this means that people won't have<br>
>> arcanist setup, and therefore are less likely to actually iterate on<br>
>> their PR.  Perhaps we should extend this to the following:<br>
>><br>
>> 3) Subsequent pushes to the branch for the PR will update the<br>
>> Phabricator differential as if you had pushed via Arcanist.  I think<br>
>> with this in place, we would have a fully streamlined system that<br>
>> allows people to use their familiar GitHub workflows, without needing<br>
>> to learn Arcanist.  Interactions would then still occur on , of<br>
>> course.<br>
>><br>
>> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"<br>
>> tool!  Could name the bot that, though!<br>
>><br>
>> Thoughts?  I think it would be great for this to be proposed formally<br>
>> soon so that we can make it happen.  I am eager to be able to use my<br>
>> normal git workflows, as my little experience with Arcanist induced<br>
>> some head-scratching.  Not the fault of the tool, just a result of<br>
>> lack of familiarity.<br>
>><br>
>> -Michael<br>
>><br>
>> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>> wrote:<br>
>>> To sum up, this proposes the following:<br>
>>><br>
>>> 1. Allow PRs on GitHub.<br>
>>><br>
>>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors.<br>
>>><br>
>>> 3. Small GitHub PRs can be merged directly, by ghc-hub.<br>
>>><br>
>>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution.<br>
>>><br>
>>> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while.<br>
>>><br>
>>> Is this worth sending through ghc-proposals?<br>
>>><br>
>>> Thanks for volunteering item (2), Michael!<br>
>>><br>
>>> Richard<br>
>>><br>
>>> -=-=-=-=-=-=-=-=-=-=-<br>
>>> Richard A. Eisenberg<br>
>>> Asst. Prof. of Computer Science<br>
>>> Bryn Mawr College<br>
>>> Bryn Mawr, PA, USA<br>
>>> <a href="http://cs.brynmawr.edu/~rae" rel="noreferrer" target="_blank">cs.brynmawr.edu/~rae</a><br>
>>><br>
>>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org" target="_blank">chak@justtesting.org</a>> wrote:<br>
>>>><br>
>>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention.<br>
>>>><br>
>>>> Manuel<br>
>>>><br>
>>>>> Michael Sloan <<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>>:<br>
>>>>><br>
>>>>> Argh, sent too soon.  The first paragraph, revised:<br>
>>>>><br>
>>>>> This sounds like an ideal solution, Ben!  As has been discussed many<br>
>>>>> times before, GitHub has many users familiar with its interface.  By<br>
>>>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If<br>
>>>>> there is an easy and straightforward process for shifting big patches<br>
>>>>> to Phabricator, then people who are regularly contributing via GitHub<br>
>>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist<br>
>>>>> workflow.<br>
>>>>><br>
>>>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan <<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>> wrote:<br>
>>>>>> This sounds like an ideal solution, Ben!  As has been discussed many<br>
>>>>>> times before, GitHub has many users familiar with its interface.  By<br>
>>>>>> allowing GitHub PRs, the initial contribution<br>
>>>>>><br>
>>>>>> I think it would be acceptable for larger GitHub PRs to have some<br>
>>>>>> automated boilerplate response.  Ideally this would look like:<br>
>>>>>><br>
>>>>>> """<br>
>>>>>> Thanks for making this patch!  I've turned this into a Phab<br>
>>>>>> Differential xxx and closed this PR.  Please create a differential<br>
>>>>>> account associated with your email address ..."<br>
>>>>>> """<br>
>>>>>><br>
>>>>>> The email address can be automatically pulled from commit metadata.<br>
>>>>>> If one is absent, then this automated process isn't possible.  If it<br>
>>>>>> is present and<br>
>>>>>><br>
>>>>>> So, I'm imagining a utility that interfaces between both GitHub and<br>
>>>>>> Phab,allowing the following commands:<br>
>>>>>><br>
>>>>>> * "ghc-hub migrate <a href="https://github.com/ghc/ghc/pull/1" rel="noreferrer" target="_blank">https://github.com/ghc/ghc/pul<wbr>l/1</a>" - migrates the<br>
>>>>>> patch to differential.  It may attempt to migrate body and title of<br>
>>>>>> the initial post, but lets not bother with migrating any review data.<br>
>>>>>><br>
>>>>>> * "ghc-hub merge <a href="https://github.com/ghc/ghc/pull/1" rel="noreferrer" target="_blank">https://github.com/ghc/ghc/pul<wbr>l/1</a>" - merges the<br>
>>>>>> patch.  This is used for merging small patches.  It would not do an<br>
>>>>>> automated push.  Maybe have "--push" also perform the push?  So like<br>
>>>>>> if you are on master, then "ghc-hub merge<br>
>>>>>> <a href="https://github.com/ghc/ghc/pull/1" rel="noreferrer" target="_blank">https://github.com/ghc/ghc/pul<wbr>l/1</a> --push" would merge the patches and<br>
>>>>>> push to master.<br>
>>>>>><br>
>>>>>> How does this sound?  I like the idea a lot, and would enjoy helping<br>
>>>>>> with implementation, time permitting.  I could possibly start hacking<br>
>>>>>> on it if others give the go ahead of "Yes, lets do that".<br>
>>>>>><br>
>>>>>> -Michael<br>
>>>>>><br>
>>>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari <<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>> wrote:<br>
>>>>>>> Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> writes:<br>
>>>>>>><br>
>>>>>>>> In writing the following huge wall of text, I had and idea that I think<br>
>>>>>>>> many folks would find palatable:<br>
>>>>>>>><br>
>>>>>>>> What if simple small patches (such as hypothetical drive by doc patches )<br>
>>>>>>>> had a mailing list where folks could email the simple / small patches as<br>
>>>>>>>> email attachments plus a body text that summarizes the patch, what it does,<br>
>>>>>>>> and why it's simple!<br>
>>>>>>>><br>
>>>>>>> I completely agree that for small (e.g. documentation) patches our<br>
>>>>>>> current system is quite heavy. For this reason I suggested at ICFP that<br>
>>>>>>> we simply begin accepting small patches via GitHub pull requests.<br>
>>>>>>> Frankly, this is less work for me than merging patches from a mailing<br>
>>>>>>> list and I believe many users feel that GitHub is more accessible than a<br>
>>>>>>> mailing list.<br>
>>>>>>><br>
>>>>>>> The problem of course is what subset of patches do we want to allow to<br>
>>>>>>> be taken via GitHub. My suggested answer to that is any patch which, if<br>
>>>>>>> I were to write it myself, I would feel comfortable pushing directly to<br>
>>>>>>> the tree.<br>
>>>>>>><br>
>>>>>>> Then there is the question of what do we do with pull requests opened<br>
>>>>>>> which do not satisfy this criterion. In this case I would likely open a<br>
>>>>>>> Phabricator Differential with the pull request and close the pull<br>
>>>>>>> request with a link to the Diff. In the ideal case this will inspire the<br>
>>>>>>> contributor to join the review process on Phabricator; in the worst case<br>
>>>>>>> review turns up issues in the patch and the user gives up. Either way, at<br>
>>>>>>> least the contributor feels his patch has been seen and given the<br>
>>>>>>> attention it deserves.<br>
>>>>>>><br>
>>>>>>> Cheers,<br>
>>>>>>><br>
>>>>>>> - Ben<br>
>>>>>>><br>
>>>>>>> ______________________________<wbr>_________________<br>
>>>>>>> ghc-devs mailing list<br>
>>>>>>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
>>>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> ghc-devs mailing list<br>
>>>>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> ghc-devs mailing list<br>
>>>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
>>><br>
><br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div></div>