CODEWITHSUNDEEP
gitphabricatorarcanist
Douglas
Douglas

Reputation: 5087

How to set up Arcanist workflow with reviewer lag time (aka stacked diffs)?

I'm fairly new to git, and even newer to Phabricator, and I'm trying to get a clean workflow set up early in my project. As I understand it, the proper thing to do with git is create a new branch for each feature, implement it in the branch, and then merge the branch into master. Works great, no problem.

Enter Phabricator and pre-push code reviews. I create a branch, let's call it "B", implement something, run "arc diff" to get it into Phabricator's Differential review system, wait for approval, and finally run "arc land" to push to the main repository. So far so good. But, I don't want to pause further development while waiting for a reviewer to get back to me.

So, I have my commit in review, and I want to start working on a refinement or dependent feature. I create a subbranch, let's call it "SB", and begin working. I get SB ready to send for review, and B is not yet approved. "arc diff" looks like it would combine the existing commit with my new changes, which I don't want - this is a new change, not an update to the old. I try "arc diff B" instead and it works, I get a new revision in Differential that includes only the new changes. B gets approved, and I run "arc land" on B to submit it. This works.

SB gets approved, and I run "arc land" on SB to submit it. I get a Usage Exception - Arcanist sees both revisions as being in SB and not in master. I try switching to master and running an update, then trying again. Same error. I try the --revision flag to land both changes (even though one of them really has been landed already). I get merge conflicts. I resolve and commit the merge conflicts and try again. I get exactly the same merge conflicts all over again.

I eventually get the idea of trying a rebase on SB, and that finally gets "arc land" to work properly. So, I have a technically working solution, but this seems kludgy and awkward to me. Is there a better way to do it that avoids the need for manual rebasing just to get Arcanist to recognize that no, the revision that I already landed is not part of what I'm landing now?

Upvotes: 5

Views: 2488

Answers (2)

Noel Yap
Noel Yap

Reputation: 19798

The following worked for me:

  1. git checkout master
  2. git checkout -b task-1
  3. arc diff
  4. git checkout -b task-2
  5. arc diff --create task-1

After changes are made on task-1:

  1. git checkout task-2
  2. git rebase task-1
  3. Resolve any conflicts

Once task-1 has been approved:

  1. git checkout task-1
  2. arc land task-1
  3. git checkout task-2
  4. git rebase origin/master
  5. Resolve any conflicts

Upvotes: 1

CEPA
CEPA

Reputation: 2602

Typically, with Arcanist, you will create each branch off master. This will prevent the issue described in paragraph 3.

Workflow would like like this:

  1. Pull master's current code
  2. Use arc branch B to create a local branch
  3. Code your changes and use arc diff to diff your code
  4. Checkout master again and pull the current code
  5. Use arc branch SB to create a local branch
  6. Code your changes and use arc diff to diff your code

There would still be a merge or rebase that would need to take place once B is landed onto master.

If you don't want to base SB off master and really want it based off B, then you will need to specify the base by using arc diff B This too will resolve the issue described in paragraph 3. Unfortunately, this options will not prevent the merge conflicts in paragraph 4. You will have to rebase SB before landing to prevent that.

Upvotes: 2

Related Questions