>> Beau <b...@adres.pl> wrote: > 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.
Refactoring with code review is hard... If you refactor code, whole merging magic is usually making more harm than good. What I would suggest: * Try to keep refactoring changes separate to functional changes * You can try to separate independent changes and have a common parent for them Ideally, the commit tree could look like: P ------ | \ \ | \ \ r1 r2 c1 |\ \ | \ \ c2 c3 c4 r1 - refactoring change 1 r2 - independent refactoring change 2 c1 - independent functional change c2,c3 - functional changes after refactoring 1 c4 - functional change after refactoring 2 You can achieve this by goint back to parent every time you are finished with some other change: git checkout <parent> or git reset --soft <parent> (if you already have changes pending) Make sure to have separate Change ID's for c2 and c3 otherwise they might end up as two patchsets of the same change. //Saper _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
