On Tue, Mar 27, 2012 at 6:06 AM, Tim Starling <tstarling(a)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