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.