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.
--
Antoine "hashar" Musso