On Thu, Feb 23, 2012 at 1:43 PM, Antoine Musso hashar+wmf@free.fr wrote:
- 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