On 04/04/2016 10:33 AM, Ted Mielczarek wrote:
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
To be pedantic, not public() is slightly more correct than draft(),
because you could theoretically mark something as secret(). But since
I'm guessing that neither of us ever do that, there's no practical
difference. (Marking things secret is just a way to prevent yourself
from pushing them accidentally. Which I've done, usually between two
local repos, since they default to being publishing. So I suppose
perhaps I could benefit from marking changesets secret by default, and
changing them to draft as part of the landing procedure. But I haven't
gone there yet.)
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.
Yeah, that was what my alias che alias does, though I should note that
recent hg finally added a sane default to histedit. It's a PITA if you
are forced to specify the base rev.
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.
Same here, but I rely on chistedit (specifically, my che alias) to do
this visually. |hg che|, j/k to navigate through the "patch series", J/K
to drag fixup patches just underneath the patches they apply to, r to
roll them up (aka fold them in and discard their comments). It's quick,
it's obvious what you're starting from and ending up with, and it even
warns you if you're reordering patches that touch the same file (which
is ok, but makes it *possible* that you might be producing conflicts
that you'll need to resolve.) It also give that same comfortable sense
of orientation with respect to your current work that I used to get from
frequent qseries -v calls.
Ted is probably well aware, but I'd also like to expand a little on how
this fixup process works. You have a series of logical changes in your
"patch stack", then you fix some bugs by changing a bunch of stuff. Then
you want to split out your working directory modifications into fixup
patches that apply to various of the "real" patches in your stack. I
tend to use commit messages like 'M-foo' where "foo" is a shorthand
description of which patch I'm updating, just so I don't have to
remember it later. So I'll do |hg commit -i -m M-foo| followed by |hg
commit -i -m M-bar| ending with a final |hg commit -m M-baz|. That
produces a couple of fixup patches, and I run |hg che| as above to fold
them together. (Be sure you have [experimental] crecord = True so commit
-i will use the slick crecord interface for selecting chunks.)
And yeah, if you're just updating the tipmost patch, skip all of that
and do |hg amend|.
Through all of this, hg will be threading your history through the
actual dag itself using precursor and successor links, which you can
hopefully be blissfully unaware of most of the time but will enable you
to view or revert to previous versions of patches if you need to. evolve
currently doesn't maintain all of the markers it should, so occasionally
you'll have to deal with divergent changesets when pushing and
reanimated corpses of obsolete changesets when rebasing, but that
doesn't affect the active stack that you really care about so it's more
of a nuisance than anything else. (I'm hopeful that
https://bz.mercurial-scm.org/show_bug.cgi?id=4210 will be fixed soonish.)
The most annoying part of my workflow is when I accidentally get some
fragments of earlier patches mixed together and need to split them up.
|hg split| is good, but then I need to rebase the descendants. I wish
there were an |hg split --amend| or |hg split --rebase| or something,
where it does the rebase for me. (/me files a bug:
https://bz.mercurial-scm.org/show_bug.cgi?id=5175 )
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
