<div dir="ltr"><div dir="ltr">On Tue, Jan 28, 2020 at 8:23 AM Renato Golin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But during the review, rewriting history of the series itself makes it<br>
hard for any review tool to have meaningful representations.<br></blockquote><div><br></div><div>This isn't really true for *any* review tool -- some are written to handle this well. E.g. Gerrit is designed exactly for this flow.</div><div><br></div><div>In order to track the commits, it uses a "logical identity" for a commit (similar to Phabricator's "Differential Revision:" line), separate from the commit hash. A local commit hook is used to automatically generate a random number (well, it's a hash of something, but may-as-well be a random number), and appends it to the commit message (e.g. "Change-Id: I0123456789abcdef0123456789abcdef01234567"). This ID subsequently serves as the review permalink and identity. Because it's in the message, it's preserved across rebases and amends.</div><div><br></div><div>Anyways, given that ID, it's easy to track the evolution of each commit in your branch separately, and treat them as separately-reviewable changes, which can each be individually ammended in response to review feedback.</div><div><br></div><div>Gerrit also makes it easy to upload an entire branch worth of commits -- just "git push" your branch to the magic-review-upload "branch" on the server. When you do that, every commit on your local branch either creates a new review or updates the existing review automatically. And all the reviews are linked together, so you can see the entire chain of reviews for the branch. (example, see "Relation Chain" on the right: <a href="https://go-review.googlesource.com/c/go/+/216221/2">https://go-review.googlesource.com/c/go/+/216221/2</a>).</div><div><br></div><div>I think this is much nicer than Phabricator's method, because the Change-Id is added to the message *before* it's uploaded, rather than having to go back and amend each message after first upload to insert the server-assigned id. And the entity which is uploaded is an actual git commit, which means it can be more easily worked with (e.g. fetched by someone else), similar to what you can do with github pull requests.</div><div><br></div><div>...But I'm not sure bringing up yet another tool really helps anything here...sorry. =p</div></div></div>