Difficulties with permanence of obsolete markers
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Tue Aug 2 14:06:48 UTC 2016
On 08/02/2016 03:38 PM, Scott Bilas wrote:
> There is one more wrinkle that I would appreciate some advice on.
>
> In order to give ourselves an escape hatch, we started using `--keep` to
> permit review of the rebase/histedit, plus a later prune to "commit" the
> edit. However, this apparently makes evolve lose the path for unstable
> commits. Rather than evolving children of a rebased commit to the new
> commit, it wants to move them to the first un-pruned ancestor, which is
> usually the wrong place.
>
> It makes sense to me why this is happening - by splitting the graft from
> prune, we're probably stopping setup of a pointer for evolve to follow.
>
> So we're in a situation where either we rebase, and have no easy+safe
> ability to undo (as per my original email), or we split the operations,
> and lose the easy+safe ability of evolve to pick the correct new parent.
>
> I'm inclined to go back to ordinary rebase, and write a scripty local
> tool (my python/hgext powers are very weak) to support undo of a messed
> up rebase/histedit via debugobsolete.
>
> Any advice for us? :)
Have you looked at the `hg prune --succ` option ?|
--
Pierre-Yves David
More information about the Evolve-testers
mailing list