Recent evolve --all changes
Matt Harbison
mharbison72 at gmail.com
Tue Apr 30 01:41:31 UTC 2019
On Mon, 29 Apr 2019 11:55:21 -0400, Josef 'Jeff' Sipek
<jeffpc at josefsipek.net> wrote:
> Hello,
>
> I recently updated and that pulled in 3ef96578 which adds an implicit
> --all
> to 'hg evolve'. I have a couple of problems with that (or maybe it is my
> workflow that needs tweaking).
>
> 1) Before the change, 'hg evolve' would evolve only one cset, now it
> evolves
> everything (all descendants? I haven't experimented enough). This is
> rather annoying when I check out an older cset with the intention of
> amending it. Consider the (for me) common workflow:
> a) check out an older cset
> b) edit
> c) 'hg amend'
> d) 'hg evolve' a few times to get enough changes into wdir
> e) run various tests, possibly going back to step (a)
> f) 'hg evolve' everything after the already evolved csets
>
> In the past this worked fine.
> With the new behavior, step (d) forces me to mentally context switch by
> forcing me to resolve all conflicts even if they are in ancestors I'm
> not
> currently working on (previously they'd be handled by step (f) above).
>
> (This happens all the time when the history is of the form: introduce
> a
> library function foo, convert codebase to use foo, introduce a library
> function bar, convert codebase to use bar.)
>
> Am I missing something? Is my workflow awkward for evolve (and it
> just
> happened to work in the past)? Is there a new way to evolve like
> there
> was previously?
Nothing weird about this workflow- I do basically the same thing.
I think I'd like to see this as a config setting, so that I can set this
once and forget about it. I'll never remember the --no-all option. I do
like the fact that all is the default for new users though. Maybe it can
be both a config setting and a command line option?
More information about the Evolve-testers
mailing list