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

[Simon Marlow]

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.

Cheers
Simon

On 29 September 2016 at 03:27, Moritz Angermann <moritz at lichtzwerge.de>
wrote:

>
> >> 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
> ^
> HEAD
>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161001/a56148c0/attachment.html>