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 <mor...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
