On Mon, Apr 4, 2016 at 11:09 AM, 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. I'd like to introduce my workflow :) I have a local base commit called "mybase", which I rebase on top of m-c every morning before I start working. All my patchesets start from this base commit. (People may sometimes see the "mybase" commit in my try pushes :) Pros: 1. I have an up-to-date codebase, and any change related to my local commits can be found in a timely manner; 2. if merge conflict happens, the three-way merge of rebase is better than the two-way merge of mq; 3. merged commits would be removed automatically as they become empty during the rebase; 4. a fixed commit makes it easier to develop tools and commands around it (I have one hg extension and several command line alias based on the existence of "mybase"). Cons: 1. rebasing takes lots of machine time, and handling merge conflicts could sometimes take much human time as well (because you have to address the conflicts as long as you keep patches in your local tree); 2. with mutable-history enabled, the accumulation of obsolete commits by rebasing could be very fast: I sometimes have ~1k hidden commits added per month (~50 local commits * 20 days) - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
