5

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?

Noel Yap
  • 18,822
  • 21
  • 92
  • 144
Douglas
  • 5,017
  • 1
  • 14
  • 28
  • 1
    This question seems like it has been taken out from my mind and put here. I am just in the same situation. Have you finally found out a better workflow? – Apperside Oct 30 '16 at 18:43
  • @Apperside Unfortunately not. I've just gotten in the habit of rebasing SB onto master before landing it every time. – Douglas Oct 30 '16 at 20:35
  • we can go to Mars, we can't do this, what a shame!! Anyway thanks for your answer – Apperside Oct 31 '16 at 08:56

2 Answers2

2

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.

CEPA
  • 2,592
  • 25
  • 31
  • It seems you're pretty much telling me that what I already worked out is the best I can do. Is there really no way to configure Arcanist to handle these issues automatically? – Douglas Sep 30 '14 at 06:11
  • For getting the right diff base on the sub branch, the documentation I found at https://secure.phabricator.com/book/phabricator/article/arcanist_commit_ranges/ for a git:branch-unique(*) rule looked promising, but none of the variations I tried on it worked. For landing the sub branch, is there no way to get Arcanist to automatically do the appropriate rebase, say rebasing all sub branches when landing a parent branch? – Douglas Sep 30 '14 at 06:17
0

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
Noel Yap
  • 18,822
  • 21
  • 92
  • 144