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. -David -- ๐ L. David Baron http://dbaron.org/ ๐ ๐ข Mozilla https://www.mozilla.org/ ๐ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
