On Thu, Feb 23, 2012 at 1:43 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:
2) newbie spamming gerrit
This happen when you first play with Gerrit.
In subversion world, whenever you submit a new patch (svn commit) it is
going to be written down in the central repository. You will not be able to
change it, hence any subsequent submission based on it are guaranteed it is
not going to change.
In git world, as I understand it, each commit as a parent commit. The
reference is a sha1 based on the content of the commit. Whenever you change
a commit, every children, grand-children .. will have their sha1 recomputed.
Enter in Gerrit world, when we send a commit in a queue, there is no
guarantee that commit will end up in the reference repo. It might be amended
or simply rejected. So your list of commit will be recomputed and all child
/ grand children will need to be resubmitted.
Guess that? That will update of all those Gerrit changes, making mass email
spam / jenkins rebuild etc.
You're right that this is the biggest problem with stacked commits: if
you have a dependency chain A-B-C and B is amended or abandoned, you
have to rebase C somehow. A lesser problem is that if A and C are
approved, but B hasn't been reviewed yet, A will be merged but C won't
be (because it can't be merged without also merging B, and B has not
been approved yet).
So yeah, we want to encourage people to use separate branches for
unrelated commits, so that B doesn't depend on A if A and B are
totally unrelated to each other. I've been trying to work that into
the various documentation pages, and Sumana let me put it in her git
introduction talk script too :)
Roan