I added a description of the workflow for multiple dependent diffs here:
https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Workingwithmultipledependentdiffs
Please let me know if anything doesn't make sense. Note that I never let
arc squash my commits, keeping commits 1:1 with diffs makes things
On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow wrote:
> A nice trick for dealing with stacked diffs in Phabricator is to use "git
> rebase -i" to modify diffs in the middle of the stack. You can also insert
> "x arc diff" between lines to automatically update later diffs on
>
A nice trick for dealing with stacked diffs in Phabricator is to use "git
rebase -i" to modify diffs in the middle of the stack. You can also insert
"x arc diff" between lines to automatically update later diffs on
Phabricator after a rebase lower down the stack.
You only need a single branch
Thanks for the useful data point Mathieu. I think it should also be
noted that GHC contributions spiked after switching to phabricator so
it could just be the effect of moving to *some* code review tool.
Could you perhaps summarise the salient points in the LLVM thread? It
is very long with lots
Hi Richard!
thanks for creating the pull request with a full proposal. You beat me to
it - tried writing up much the same before stopping for dinner, essentially
capturing just one of the points in Moritz's earlier (large) proposal.
Moritz, I would encourage you like Richard did earlier to split
I have tried to gather the ideas from this thread into a formal proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/11
Please feel free to make suggestions to improve this, especially if I've
captured anyone's contributions incorrectly.
-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
On Wednesday, September 28, 2016, Eric Seidel wrote:
> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the
Hi,
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.
A workflow I've used a few times is to craft a nice sequence of commits for
review and, once
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> Moritz Angermann writes:
>
> > All that arc essentially does is, compute the diff from an offset
> > (e.g. master) to the current HEAD and upload that to a new or existing
> > (--update) differential. It also adds some
>> Hence you can go wild on your local branches (use what ever
>> development model suites your needs) and get one final squashed commit
>> with an extensive summary.
>>
> Sure, but this leads to generally unreviewable patches IMHO. In order to
> stay sane I generally split up my work into a set
Moritz Angermann writes:
> I don't think Phabricator tries to be or emulate fit in any way; I
> think this is a misconception. The way I see it, phabricator is just a
> glorified diff-dump, which is supposed to work with any VCS in
> principle.
>
> All that arc essentially
I don't think Phabricator tries to be or emulate fit in any way; I think this
is a misconception. The way I see it, phabricator is just a glorified
diff-dump, which is supposed to work with any VCS in principle.
All that arc essentially does is, compute the diff from an offset (e.g. master)
to
On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote:
> That being said, I ultimately decided it would be easier to just
> continue carrying out this workflow by hand considering I don't post
> large series of patches *that* often. I'm also a bit more eager to
> squash now
Simon Marlow writes:
> 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.
>
I have considered
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.
Perhaps you could build something that would allow revisions to PRs
Exactly! So we will be using Phabricator for the review process, but
with the github PRs you can use plain git. This means that new
contributors will only need to learn about phabricator, and arc will
be non-mandatory though probably recommended.
Glad you like the idea :)
-Michael
On Tue, Sep
On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann wrote:
> Hi,
>
> I think it would be great if this was proposed formally. If we could
> integrate this with the improved ghc development proposal[1], this
> would be great! Or turn it into a separate proposal and remove the
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.
Richard
> On Sep 27,
You're welcome Richard! I look forward to helping make it happen. In
the other thread, Alexander Vershilov mentioned that we might instead
consider the following more straightforward workflow:
0) Have a bot that watches github for PRs.
1) Submit whatever you want to github as a PR.
2) It will
Sounds like a great idea to me and might alleviate SimonM’s concerns about
fragmentation of dev attention.
Manuel
> Michael Sloan :
>
> Argh, sent too soon. The first paragraph, revised:
>
> This sounds like an ideal solution, Ben! As has been discussed many
> times
Argh, sent too soon. The first paragraph, revised:
This sounds like an ideal solution, Ben! As has been discussed many
times before, GitHub has many users familiar with its interface. By
allowing GitHub PRs, the initial contribution barrier will be lowered. If
there is an easy and
This sounds like an ideal solution, Ben! As has been discussed many
times before, GitHub has many users familiar with its interface. By
allowing GitHub PRs, the initial contribution
I think it would be acceptable for larger GitHub PRs to have some
automated boilerplate response. Ideally this
Phyx writes:
> I dislike this approach, having to already deal with a project that does
> patches via mailing lists it is very hard to follow conversations. As soon
> as multiple people get involved things fall apart.
>
I think accepting pull requests via GitHub can be done
Carter Schonwald writes:
> In writing the following huge wall of text, I had and idea that I think
> many folks would find palatable:
>
> What if simple small patches (such as hypothetical drive by doc patches )
> had a mailing list where folks could email the simple
> "CS" == Carter Schonwald writes:
CS> What if simple small patches (such as hypothetical drive by doc patches )
CS> had a mailing list where folks could email the simple / small patches as
CS> email attachments plus a body text that summarizes the patch, what it
I dislike this approach, having to already deal with a project that does
patches via mailing lists it is very hard to follow conversations. As soon
as multiple people get involved things fall apart.
I have multiple mailing rules and other things just so I can keep track of
comments. And then
I like this solution a lot, Carter!
Mailing patches directly to the ghc-devs list could be intimidating
for newcomers. Having a list specific to patch review could make the
process less intimidating. From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton
In writing the following huge wall of text, I had and idea that I think
many folks would find palatable:
What if simple small patches (such as hypothetical drive by doc patches )
had a mailing list where folks could email the simple / small patches as
email attachments plus a body text that
28 matches
Mail list logo