Help designing the evolve UI

Martin Geisler martin at geisler.net
Mon Apr 21 05:17:08 CDT 2014


Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> On Sat, Apr 19, 2014 at 1:31 AM, Sean Farley
> <sean.michael.farley at gmail.com> wrote:
>>
>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>
>> An obsolete marker is (currently) just a list of the form:
>>
>> OLD_NODE [OPTIONAL NEW_NODE] FLAGS {dictionary of user, date, and parent node}
>>
>>> It is not all that clear to me when obsolete revisions are pushed to
>>> a server:
>>
>> They are _never_ pushed to the server. If you want to strip the
>> obsolete *changeset*, then fine. Removing the marker is what should
>> not be allowed.
>
> OK, thanks for the clarification.

Hmm, it this really true? I would expect the obsolete marker to be
pushed to the server if the now-obsolete commit is on the server.

> I'm starting to think that perhaps, as you said, I'm looking at this
> wrong.
>
> Through this whole thread I've been trying to express a certain
> feeling of loss of control and of unnecessary complexity that I get
> when using evolve. I don't like that it may seem that I'm being a bit
> contrarian or even a luddite but I really am not trying to be. I just
> hope that some of these comments help make the final version of evolve
> a little better.

I don't think you're being contrarian at all -- I think it's awesome
that you're already experiementing with the extension. You bring
valuable input about how it works when you mostly use TortoiseHg. That's
a really important approach.

> The official position seems to be that I should not care about the
> extra hidden commits, but if we want for users to be able to ever use
> the safety net that evolve provides I think the hidden history should
> be as usable as possible, and 5 extra commits for a single failed
> experiment is perhaps a bit too much.

It feels like a lot to me too. I felt a similar thing when I amended two
commits out of six and had to run 'hg evolve' six times to get back to a
good state.

I ended up with 10 hidden commits. The optimal case would have been five
hidden commits since I amended commit 2, so the old 2-6 must be hidden.
I'm unsure if evolve could somehow plan ahead and get to the optimal
result.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140421/8a55ddb3/attachment.pgp>


More information about the Mercurial-devel mailing list