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