On 2016-04-04 10:07 AM, Eric Rescorla wrote: > On Sun, Apr 3, 2016 at 10:09 PM, L. David Baron <dba...@dbaron.org> wrote: > >> On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote: >>> 1. I write a bunch of code, committing along the way, so I have a lot of >>> commits named "Checkpoint" and "Fix bug" and the like. >>> 2. When it works, I push the code up to the review system for review. >>> 3. In response to review comments, I add a bunch more changes as new >>> commits and push them up the review system for review. >>> 4. Repeat 2 and 3 until I get r+ >>> 5. Squash everything into one commit and land it. >>> >>> Every time I do #3, it creates a new review request, but as you can see, >>> this doesn't have any meaningful connection to my local commits, which >> is a >>> good thing because while I want to keep my local history, I don't want it >>> to show up either in review or in the tree. This is also the way I want >> to >>> see patches because I want to review the whole thing at once. >> >> This is why I use mq. With mq, I maintain the sequence of >> changesets that are the logical units to be committed (and submitted >> for review), and I have the history of that sequence (in a >> version-controlled patch repository). >> >> It's useful for reviewability and for bisection for the logical >> units that I commit to be small and (for review) understandable. >> And it's useful for me to have a history of the work I've done, for >> backups, for the ability to revert, and for the ability to remember >> what I did and why. >> >> I still think this is a good model for doing development, despite >> the attempts of Mercurial developers to deprecate it. I recognize >> that it's not the right tool for everybody, though. >> > > Fair enough, but I use git :) > > I generally don't have trouble keeping the logical changesets straight > with git and git rebase, which is good about merging and splitting. > > I'd like to state for the record that I'm not trying to change anyone's > workflow nor am I trying to create a lot of work for reviewers. I'm simply > asking for the tools to accommodate the workflow that I and a bunch of > other people use, said accommodation being, I believe, relatively > modest.
Indeed, we talked about supporting this before, and it is planned; see https://bugzilla.mozilla.org/show_bug.cgi?id=1217861. However right now we are focussing on UI issues to improve reviewer experience. Early MozReview development was focussed mainly on author experience (admittedly largely for Mercurial-using developers), which got a lot of people using MozReview, but that in turn surfaced a lot of confusion and suboptimal workflows for reviewers. I'd like to keep focussed on that for the next quarter or so, since reviewer time is generally perceived to be more valuable than author time. To answer the original question, though, at this time we have no plans to completely do away with the squashed-commit view. However, in the interests of ensuring that the commits that will land are the ones reviewed, we are thinking of making the squashed diff read-only--and also more obvious and easy to find, probably by not making it a proper review request, just a diff linked off the commit table (the layout of which we also have plans to improve). I agree that seeing the entirety of a series of commits in a single diff can be useful. Mark _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
