Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

Simon Marlow marlowsd at
Sat Oct 1 20:47:13 UTC 2016

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 for the whole stack, and continually rebase
it.  I also push the whole branch to github to get Travis to build it, but
that's optional.


On 29 September 2016 at 03:27, Moritz Angermann <moritz at>

> >> 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 of standalone patches
> > with git rebase and then create a Diff of each of these commits.
> > Phabricator supports this by having a notion of dependencies between
> > Diffs, but arcanist has no sensible scheme for taking a branch and
> > conveniently producing a series of Diffs.
> Yes, this has been a constant source of frustration for us as well. Dealing
> with dependent diffs is just plain painful with arc :( What I usually end
> up
> doing, and I assume that’s what you are describing is:
> Turning
> A -- B -- C -- D -- E -- F -- origin/master
> ^
> into:
> branch B1:                  E -- F -- origin/master
>                           /
> branch B2:          C -- D
>                   /
> branch B3: A -- B
> and producing three diffs:
> $ git checkout E
> $ arc diff origin/master # producing D1
> $ git checkout C
> $ arc diff B1 # adding “depends on D1" into the summary field
> $ git checkout A
> $ git diff B2 # adding “depends on D2” into the summary field
> and then rebase B2 and B3 when changes to D1 on B1 are necessary.
> Running `arc patch` with dependent diffs often resulted in trouble;
> this seems to be getting better with the staging areas though.
> So clearly we can see there are drawbacks.  All I wanted to say in
> the previous email was essentially that from my experience frustration
> with arc often came from trying to make arc be git.
> Cheers,
>  Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list