From my personal experience, it is common as a developer that you have features/bug fixes that are based on other features / bug fixes.
Here is an example. Let's say that I have two bug fixes which has their own tasks in Phabricator; T1 and T2. However, in order to solve the bug of T2, I first need to solve T1.
So, let's say I do an arc feature t1 from master, solve the bug described in the task T1, I send that in to code review via arc diff, which creates the a differential revision D1.
Now since in order to solve T2 I needed D1, I stand in that branch and do arc feature t2. Do my changes and push it up with arc diff which creates D2.
Branch-wise it means my branches local looks like this: master -> t1 -> t2.
Revision wise, it looks like this: D1 -> D2.
I think this is pretty common right in software development, right? That you have branches or commits that are based on each other to make small changes that are easier to code review and belongs to a specific code change intent.
However, it seems like Phabricator doesn't support this flow at all?
Because let's say one of my colleagues needs to download D2 and test it locally on their computer. But when they type arc patch D2 they get the error message This diff is against commit [SHA-key of the first commit], but the commit is nowhere in the working copy..
I must be missing something here. How are you suppose to use Phabricator with changes that depends on other changes? Because this is pretty normal way to work, right?
Any feedback would be appreciated!
I use this flow regularly, so we support it empirically, although some aspects of it could be improved.
You can use Depends on Dxxx in your summary to mark a dependency formally. See T5132 for other supported syntax. This is shown in a commit message tip during arc diff, but its appearance is random and I think these tips are not actually very effective in teaching features to users:
Create a dependency between revisions by writing "Depends on Dxxx" in your summary.
We should attempt to infer these dependencies in a broader range of cases than we currently do. See T6232 for some discussion.
When dependencies are marked, arc patch attempts to apply them in order. This may have some outstanding issues (T6482 seems to describe at least one). Generally, arc patch is overdue for updating and many modern features (like staging areas) could improve its behavior and make it more reliable and flexible.
Later, after landing, you may need to iteratively rebase stacks of changes. arc could introduce some command or workflow to make this easier (see T3875).
See also Arcanist Workflows, perhaps.