Evolve feedbacks

[Pierre-Yves David]

On 05/19/2015 12:07 AM, Gilles Moris 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.

We know we miss such feature and we would like to get it. We know how to 
compute such information, someone need to draft the UI and produce some 
patch.

> - Even though evolve is non destructive, it is not obvious how to
> recover that past information:

We also want to improve that aspect, but nobody is working on it yet. 
There is a couple of idea to be tested if someone want to get some code 
written.

>    * 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:

Improving documentation, revset name is definitely on the roadmap. Some 
kind of unfiltering (or special commands) to access the obsolete history 
is to be expected too.

>    * 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().

Generic unfiltering of all hidden changeset will likely provide too 
broad results. We probably want to do target unfiltered to the context 
of what you are asking for.

We offer a hint about --hidden for make it more discoverable.

   $ hg log -r b9d6b90c706f
   abort: hidden revision 'b9d6b90c706f'!
   (use --hidden to access hidden revisions)

If you think the (new) evolve doc does not advertise --hidden properly, 
feel free to suggest update.

>    * 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.

As David pointed, hgview and tortoige-hg can display and navigate this 
information.

>    * 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.

There is some basic commands 'olog' and 'odiff' who display the most 
direct precursors and a diff againts it. hgview will let your see the 
diff againts a precursors/successors too.

> - 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?
>    * Generalization: how do you handle patch re-ordering with evolve?

There is a plan for a "Plan" feature that would allow that.

> - 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?

You can get some of this here:

   https://mercurial.selenic.com/wiki/ChangesetEvolutionDeve

>
> Regards.
> Gilles.
> PS: given the low traffic on evolve mailing list, should this go to
> mercurial-devel instead?

Design discussion goes on mercurial-devel, user feedback and discussion 
for here. I think your email is good here.

-- 
Pierre-Yves David