On Tue, Mar 27, 2012 at 6:06 AM, Tim Starling tstarling@wikimedia.org wrote:
I could not find a recommendation to use --amend in the Gerrit manual. The manual says that it is possible to submit subsequent commits to the same change by just adding a Change-Id footer to the commit message. That seems to be the reason for the copy button next to the Change-Id on the change page.
When I tried to do a test push containing several commits which depended on each other, but with the same Change-Id, Gerrit rejected it. But I'm not sure if that's a configuration issue or if it just expected them to be done in separate pushes.
If it was possible to follow the Gerrit manual in this way, and submit non-amending followup commits with the same Change-Id, then we'd have the comment grouping advantages without the code review disadvantages.
Yes, that works. And actually, I think it's a little bit easier. It's a little more "manual" that trying git one-liners, but it seems to at least *always* work (and I've used it a couple of times to fix changes with totally botched history).
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.
Tell people to not amend their commits then.
Also making sure people don't have unrelated commits showing up as dependencies makes the process much easier. If two things aren't related--don't relate them!
-Chad