Niklas Hambüchen writes:
..[snip].
>
> So I've found it a big pain to maintain a series of dependent commits with
> this workflow.
>
> I can imagine this to be only painless if you have access to the tooling you
> said you have at facebook, that automates these things for you.
>
> In my ideal
On Fri, 5 Oct 2018 at 15:22, Niklas Hambüchen wrote:
> > I think the article is assuming the base for `arc diff` is always the
> parent revision, i.e. `arc diff HEAD^`, which is how the workflow works
> best. Strangely I don't think the open source Phabricator is set up to do
> this by default
I think the article is assuming the base for `arc diff` is always the
parent revision, i.e. `arc diff HEAD^`, which is how the workflow works
best. Strangely I don't think the open source Phabricator is set up to do
this by default so you have to actually type `arc diff HEAD^` (there's
probably
There are some things in these argumentations that I don't get.
When you have a stack of commits on top of master, like:
* C
|
* B
|
* A
|
* master
What do you use as base for `arc diff` for each of them?
If B depends on A (the patch expressed by B doesn't apply if A was applied
first),
do
Here's an interesting blog post relevant to previous discussions about
Phabricator / GitHub:
https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3JyQP5uCn6ENiHOTWd41y5D-U0_CCJ55_23nzKeUYTjgLASHu2dq5QCc0
Yes it's a decidedly pro-Phabricator rant, but it does go into a lot of
