Help designing the evolve UI

Sean Farley sean.michael.farley at gmail.com
Mon Apr 21 11:54:26 CDT 2014


Martin Geisler <martin at geisler.net> writes:

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

They = obsolete revision / changeset. Obsolete markers are append-only
and are currently always pushed.

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

A lot of this temporary commit situation will improve when I finish
in-memory merge :-) My point throughout this thread, though, has been
not to even think about stripping obsolete markers.


More information about the Mercurial-devel mailing list