Evolve feedbacks

Matt Harbison mharbison72 at gmail.com
Wed May 20 00:06:26 UTC 2015


On Tue, 19 May 2015 03:07:21 -0400, Gilles Moris <gilles.moris at free.fr>  
wrote:

> I am currently a beginner with evolve, though I have followed the  
> introduction of the concepts those last years.
>
> Currently, I am a MQ user. I introduced its usage at work, and everybody  
> is pleased with its use, though it have some limitations that evolve  
> remedy elegantly.
> First, I am overall pleased with the usage of evolve, so I won't come  
> back on its intrinsics quality, like non destructiveness, easy merging  
> of downstream patches, etc...
>
> So below is what I am missing currently. May be some of those already  
> exists.
>
> - I would have expected an "evolve --list", much like there is a  
> "resolve --list". Basically, I need a roadmap of all the evolutions I  
> need to perform to stabilize my work tree. I guess this could be  
> partially addressed with some revsets, or "summary --verbose". But I am  
> expecting more than that. What are the suspended changesets that make  
> some commits unstable ? What is the public commit that bumped my  
> changeset? What is the list of divergent commit? I would expect an  
> "evolve --list" to give that. Giving the phases in the summary command  
> was part of the same move.
>
> - Even though evolve is non destructive, it is not obvious how to  
> recover that past information:
>    * I use allprecursors() revset to get access to that, but for a  
> typical user, it is not very easy to understand which revset to use. In  
> addition, it usually won't display anything, which is my second bullet:
>    * I think some revsets, implying hidden commit should probably  
> implicitely trigger --hidden. I don't know if this can be considered a  
> bug, but having to do: "hg log -r 'hidden()' --hidden" seems weird. And  
> the "--hidden" flag is not very dicoverable, buried in hg help -v (which  
> might be on purpose). The same could apply to precursors(), successors().

I thought there was a bug written for this, but maybe it was just recent  
chatter on the main mailing list.

>    * Is there a way to display the meta-graph of the precursors /  
> successors of a commit ? This would enable to show how we get to a  
> particular commit.

You mean this?

     $ hg log -G --hidden -r "allprecursors(26993)"

>    * By extension, I would like to see the incremental diffs introduced  
> by each  precursor. A dumb implementation for a linear obsolete  
> meta-graph can be made by doing repeatidly: "hg diff --hidden --rev  
> precuror1 --rev precursor2". Note again --hidden needed. Note also that  
> rebase will bring unrelated changes into the diff. But at least, that's  
> a start.

I miss this a lot from my MQ usage- the ability to see just how my changes  
were impacted:

     $ hg ci --mq
     $ hg pull
     $ hg rebase -s qbase -d tip
     $ hg bcompare --mq

Here's a crude script I use to get roughly the same as the last line, so  
that it avoids all of the noise in the linear diff:

#!/bin/sh

node=$1
#hash1=$(hg --hidden log -r "limit(precursors($node),1)" -T "{node|short}")
#hash2=$(hg log -r $node -T "{node|short}")
hash1=$(hg --hidden log -r $1 -T "{node|short}")
hash2=$(hg --hidden log -r $2 -T "{node|short}")

hg --hidden export -r "$hash1" -o '/tmp/%h.patch'
hg --hidden export -r "$hash2" -o '/tmp/%h.patch'

echo "comparing $hash1.patch to $hash2.patch"
bcompare.exe "/tmp/$hash1.patch" "/tmp/$hash2.patch"


Just invoke it like:

     $ odiff.sh 'precursors(x)' x

Obviously I can't put this in contrib with the diff tool hardcoded and no  
cleanup, so I started trying to wrap extdiff.  But I ran into some issues,  
and haven't gotten back to it in awhile.  I took out the internal  
precursors assumption, because it is also useful to compare grafts.  BTW,  
the odiff name comes from the 'odiff' command evolve adds, but I think  
that it includes the linear noise.


> - With prune, you can remove a patch in a linear series. How do you do  
> the reverse? Insert a new patch in a linear series. AFAICS, this  
> implies: hg update + hg commit + hg rebase. Right? If yes, this may  
> deserve a command, much like prune.
>    * Related: what would be the equivalent to: hg qpush --move. A few  
> rebase?

I think that makes sense.  I don't use histedit, so maybe there's a better  
way.  It's not specifically mentioned here, but this is an MQ -> evolve  
cheatsheet:

     http://mercurial.selenic.com/wiki/MqDeprecationPlan

>    * Generalization: how do you handle patch re-ordering with evolve?
>
> - I did not find any high level roadmap of the roll out of evolve. Will  
> it be merged back in the main HG repo as an extension? What are the  
> condition for that? What is the plan to merge it as standard HG  
> commands? When will that happen? What is missing for that to happen?
>
> Regards.
> Gilles.
> PS: given the low traffic on evolve mailing list, should this go to  
> mercurial-devel instead?
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at selenic.com
> http://selenic.com/mailman/listinfo/evolve-testers



More information about the Evolve-testers mailing list