Details
For a large related series of changes I'll often do my work as a series of branches on branches. A similar workflow is described at /w/guides/arcanist_workflows.
For example:
- git checkout -b A && do-the-work && arc diff
- git checkout -b B && do-the-work && arc diff A
- git checkout -b C && do-the-work && arc diff B
So C depends on B which depends on A. I can land A without problem. But sometimes (I'm not sure what git magic is different) run into trouble with the other commits. For example landing B will result in a merge conflict and B can not be rebased on master nor have master merged into it without conflict. However I don't think there is a "real" conflict because: (1) I can't figure out a sane way to resolve them (2) arc patch --diff-for-B applies cleanly.
I've taken to using arc patch to land the flow. That works but feels super silly. Is there a consistent way to avoid conflicts with doing the branches-on-branches?
Answers
When I hit these, I currently rebase them manually via git rebase -i using this script (gm = git rebase on master, although it now takes any branch as a target):
$ cat ~/dev/bin/gm #!/bin/sh set -x set -e TARGET=${1-master} exec sh -c "git rebase -i $TARGET && arc liberate src/ && ./bin/celerity map && git status"
This pops $EDITOR (nano) and I ^K to remove duplicate commits, then save and exit to get a clean rebase + updated rebuild.
This is fairly silly, but takes only a few seconds, and I run arc land at most a few thousand times a year, so it's hard to prioritize.
I imagine eventually giving arc more tools to handle this -- approximately, "cascading rebases", with some discussion in T3875. My script also has artifact regeneration steps, which may make sense as part of arc eventually, likely via some future arc build mechanism which is a long ways off (T5568 / T9223).