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