On Mon, Apr 4, 2016, at 12:46 PM, Steve Fink wrote:
> I should clarify that by "non-mq", I really mean using mutable-history
> aka evolve. And yes, my workflow does depend on some extensions,
> including some local stuff that I haven't cleaned up enough to publish.
> (As does my mq workflow; I had to write mqext to get painless versioning
> of my patch queue.) So I'm not saying "just switch off from mq to evolve
> and everything will be great"; rather I'm saying that with some effort
> to get accustomed to the new workflow and some customization, the
> evolve-based workflow can feel better than the mq-based workflow, even
> if you've built up a set of workarounds and accommodations to mq's
> weaknesses that you're comfortable with.
I fully agree with this. I switched over from mq to
bookmarks+mutable-history a while back and I'm now very happy with it. I
assume that anyone that's comfortable with the standard git feature
branch workflow would be happy with this as well, since it's very
similar.
I make a hg bookmark per thing I'm working on (sometimes with one thing
being a branch off of another, for dependent patches), and use `hg
amend` and `hg histedit` quite a bit. I rebase work-in-progress changes
as-needed (for landing or whenever). The nice thing of using bookmarks
vs. mq is that you always have the DAG from your changesets, so a rebase
is always a 3-way merge instead of blindly applying patches and fixing
up the rejects. I use KDiff3 for my merge tool and I'm reasonably happy
with it. I've maintained even large (20+) patch series in this manner
and haven't had issues. I've done the same with mq in the past and
rebasing was always miserable, and I would inevitably wind up with
patches in my queue that didn't apply and I didn't know the base rev
they applied against, so I'd wind up having to practically rewrite them
when I wanted to apply them in the future.
Additionally, the "stack of patches" model of mq just never fit my
actual workflow very well, where I always have multiple WIP patches in
my tree, some of which are dependent on others, but others being
independent. Having bookmarks lets me just commit things in the DAG the
way they fit together, so I can juggle all my WIP without problems.
> For me, the main thing is to stay oriented, and bookmarks plus an alias
> to do the equivalent of hg log -r 'ancestors(.) and not public()' go a
> long way towards recovering mq's "what am I working on?" qseries -v
> affordances. Though I immediately want it to be something closer to hg
> log -r 'ancestors(.) and not public()' -T '{node|short} {desc}\n' and
> then I want color etc etc... Anyway, I'll document what I have at some
> point, and other people have their own things as good or better.
I have two aliases that I find invaluable, `booklog` and `bookedit`:
```
[alias]
booklog = log -r "ancestors(.) & draft()"
bookedit = histedit "first(ancestors(.) & draft())"
```
If my working directory changeset is a WIP patch, I can `hg booklog` to
see just the changes that are only in my local tree ("draft" in
Mercurial parlance) that are ancestors of the current rev, so just the
current change and anything it depends on. `bookedit` is just a handy
alias for "histedit the WIP changesets starting at the working
directory", so I can easily squash or reorder patches that I'm currently
working on.
What I find myself doing a lot is committing things in the units that
make sense, then if I need to make changes later I just commit fixup
changesets on top, and then `hg bookedit` to fold those changes back
into the changesets where they make sense. If there's only one changeset
in play, then `hg amend` is simpler, obviously.
-Ted
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
