> On Apr 4, 2016, at 10:33, Ted Mielczarek <t...@mielczarek.org> 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
> 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.
The default behavior of "hg histedit" (with no args) in mercurial 3.7 is to
select for editing all mutable ancestor changesets of the working directory
that aren't in any other DAG branch. There is also a config option to change
the default revset that histedit uses to select the base changeset to edit. You
should be able to delete your "bookedit" alias :)
>
> 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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
