On 07/05/12 10:26, Beau wrote: > I prefer making small changes, so it is easy to review and test them. > However due to not clearly determined order of merging changes I have no > idea what should I choose as my baseline. I prefer to avoid solving > merge conflicts with myself. This usually happens when changes got > reviewed and merged in for example reverse order. It is clearly a waste > of time. > > I know gerrit can use dependencies, so I can make a chain of dependant > changes: c1 <- c2 <- c3 <- c4. However if c2 and c3 got a positive > review and c1 needs some rework, c2 and c3 need to be reviewed again > after I submit c1.
> Sometimes another, unrelated change may be merged, so > the whole chain needs to be rebased against master. No. That doesn't need a rebase. They will just be merged. And -assuming they don't conflict- that should not be a problem. > The most ideal approach would be to review changes as soon as they are > submitted, but I am well aware, that there are not enough people to do > the review. > > Any thoughts? No better idea than just making dependant changes. You can join them under the same topic, and maybe provide a hint in the changeset comments to note please review ancestors before. Auto-rebase of non-merged descendants seems a good feature request. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
