EDITED to address issues with downstream CLs when the colleague's CL is updated.
I'm working closely with some of my colleagues on a project, meaning that we are frequently working on functionality that depends on CLs still in review, written by other people. The Chromium docs on how to handle this are out-of-date and contradictory, so in the fine blogging tradition of making a post so I don't forget something, here it is.
How do I make a CL that depends on another CL?
When you git cl upload, depot-tools looks in the Git history for your HEAD commit, until it finds another branch. If that branch has dependency information (unclear if that's in .git/config or a Change-Id: .. header in its commit message), then the upload will link the CLs.
First, get a local copy of the parent CL, and give it an appropriate branch name. This is my pattern, but it is only local do what suits you best!
git cl patch -b bug-$NUM-$USERNAME-$SUMMARY $GERRIT_URL
This may give an error about hashes not matching, but that's OK, since you won't be uploading to that CL. I suspect this has something to do with the committer name / email.
Then, make a new branch with that one as the upstream.
git new-branch --upstream-current bug-$NUM-$MY_SUMMARY
Make your changes. When you're ready to upload, do so as usual:
git cl upload --cp
That --cp is telling the command to not try to upload all of the other CLs in the stack.
Updating the Parent CL
When the CL you're depending on is updated, you need to use precisely the right formulation of git cl patch or things will go wildly off the rails.
Switch to the branch containing that parent CL and run
git cl patch --force --reapply
do not use --pull - I think that does something like pulling origin/main and rebasing on top of it? At any rate, it's a bad idea.
Top comments (2)
You can avoid that last prompt with
It turns out, this doesn't work if you have a stack with a depth greater than 2. Beware!