On Thu, Feb 23, 2012 at 1:43 PM, Antoine Musso <hashar+...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
