collect the latest reviews in a series

[Loic Dachary]

When working on a series of patch such as

$ git review -l
90557 master ceph::osd : indent tests
90556 master ceph::osd : add support for mon data directories
90558 master ceph::osd : add tests for mon data on an existing partition
90555 master ceph::osd : do not hardcode the cluster name
89351 master ceph::mon : control client.admin key generation
89267 master ENV['MACHINES'] overrides [first second]
89356 master update the first use case to reflect that it works
89477 master ceph::mon : tag cephx spec test
89037 master ceph::key : fix cap_{mon,osd,mds} prototype to match the documentation
89269 master ceph::key : add the cluster argument
89476 master ceph::mon : remove useless comments from tests
89352 master ceph::key : remove the client.admin keyring for tests
89354 master ceph::key : proofread documentation strings
89353 master ceph::key : reduce literal duplication in tests
89202 master ceph::key : exec touch is redundant with file
89349 master ceph::key : update copyright notice
89350 master ceph::key : remove redundant Exec blocks
89268 master reminder to run a single integration test
89258 master ceph::key : add keyring and id key injection arguments
89212 master ceph::key : make shell verbose for clarity
86491 master define ceph::pool.
Found 21 items for review

Although it does not show in the output, each review depends on the next.

One review in the middle of the series (say "89477 master ceph::mon : tag cephx spec test" for instance) is amended for cosmetic reasons or any other reason that does not require to rebase its dependencies. . If these minor changes create a merge conflict, the dependencies need to be rebased manually after being approved. To do that properly, the latest changset for each review to be rebased needs to be collected. Otherwise an obsolete patch may very well become the latest patch of the review ( say "90555 master ceph::osd : do not hardcode the cluster name" for instance). It can be done manually by:

* git review -d 90557 # i.e. the last review of the series of reviews
* git log | collect Change-id: | revert the list > list-of-reviews-from-oldest-to-newest.txt
* git branch a-new-branch
* for each list-of-reviews-from-oldest-to-newest.txt, git review -x changed-id

The merge conflicts are resolved, all at once. When complete, all patches are published with git review --yes and dispatched to the proper review.

It would be convenient to have something like:

    git review --build-branch-from-most-recent-patches 90557 # i.e. the last review of the series of reviews
    git review --yes

that would do the same, only with less manual intervention.

[Jeremy Stanley (fungi)]

Unless I'm misunderstanding, the requested behavior can mostly be accomplished with something like:

    git remote update
    git review -d 90557
    git rebase -i origin/master
    [...resolve merge conflicts as needed...]
    git review