Roan Kattouw wrote:
An unrelated disadvantage of "stacked changes" in Gerrit (i.e. changes that depend on other unmerged changes) is that if B.1 (change B patchset 1) depends on A.1, and someone amends A.1 later to produce A.2, B.1 will still depend on A.1 and will need to be rebased to depend on A.2 instead. I've done this before with a stack of four commits (amended B and had to rebase C and D), and I can tell you it's not fun. I think I've figured out a trick for it now (use an interactive rebase from the top of the stack), but it's not intuitive and I've never tried it.
We definitely need a documentation about rebasing a serie of dependant changes, I had to do that this morning.
Given changes:
A -> B -> C -> D
When A is changed, you should do something like:
Get the tip of the commit chain: git-review -d D
Then rebase either:
1) on top of the original "branch" point: git rebase A^
2) on whatever HEAD is rendered to: git rebase gerrit/master
Then submit your rebased commit chain:
git-review -f
git-review will warn you about attempting to submit several patchsets at the same time. It will list the new sha1 for each commit.
Confirm and you get four new patchsets submitted and dependencies updated.
Would need someone to cross check that and then we can amend our Gerrit documentation.