Ludovic Rousseau wrote: > Change 2 now merged. Ok!
> I also tried with change 3 > https://www.opensc-project.org/codereview/#change,3 but I get the > error: > "Gerrit Code Review 8:45 PM > > Change cannot be merged due to unsatisfiable dependencies. > > The following dependency errors were found: > > Depends on patch set 1 of I8b483369, however the current patch set is 2. > Depends on commit 3a8519eda2704eceb2d27bfbeaca44c6da7d51b2 which > has no change associated with it. > > Please rebase the change and upload a replacement commit." > > Do we now have to rebase all the patches? With the current gerrit configuration yes, unfortunately this is the case. Gerrit can also be configured differently, but I'm not sure if we want to.. In other projects where I use gerrit we do not have this rather strict policy, but it does also force contributors to pay attention to what they are doing, and if they rebase they should also look at the result of that, before pushing to gerrit again. In practise I don't know if it works; I didn't review the rebase of change 2, only the one for change 1. And while rebasing is easy in git I think it's bad that contributors are forced by gerrit to do it so much. On the other hand, changing gerrit to use submittype cherry-pick makes all dependencies merely advisory, ie. humans using gerrit must pay close attention so that nothing gets submitted out of order, or changes will have to be rebased anyway. What to choose depends on how the project will work with commits.. If we will generally have only very few very recent changes in gerrit then the current configuration can work pretty well, except that it must be clear already before pushing which commits will be submitted in gerrit before the one(s) being pushed. If we suspect that we will have some changes in gerrit which lay around for a long time without getting attention from either reviewers or contributors, and it was assumed by someone that those commits would be submitted first, then the someone will have to rebase, and everyone assuming that someone's change would go in will have to rebase in turn, and so on.. Not so nice. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
