You can now avoid re-reviews of code after a rebase with no conflicts, though you'll need a custom completion condition to do so.
There's a new
baseChangesOnly flag available to custom completion conditions. This flag is set for each revision of a file, and indicates whether all visible changes can be cleanly attributed to an edit in the base branch that was integrated into the pull request. The flag's value must first be computed in a client, so it won't be available to the condition as soon as the commits are pushed but the condition will be re-executed once the flag is ready.
We have a new sample condition that ignores base-only changes when computing completion. You can adopt it as-is, or crib from it to integrate the relevant logic into your existing one.
One subtlety about detecting base changes is which revision should be used for comparison. While a file revision's
'renamed', etc.) is always determined against the immediately preceding revision, base change detection uses the matched "prior revision" as its reference. This is often the immediately preceding one, but when rebasing multiple commits in a review following "review each commit" style Reviewable will do its best to match up each "new" commit to its semantic antecedent. You can see this in the review UI, with arcs connecting file revisions when you hover over them.
We don't surface these details about prior revisions in the condition's input data structure but our algorithm is fairly robust and biased towards needing strong evidence for a match, so false positive
baseChangesOnly flags should be extremely rare.
Let us know how this new feature works for you!