Help designing the evolve UI

[Sean Farley]

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

> On Fri, Apr 18, 2014 at 10:55 PM, Sean Farley
> <sean.michael.farley at gmail.com> wrote:
>>
>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>
>>> On Fri, Apr 18, 2014 at 12:34 PM, Martin Geisler <martin at geisler.net> wrote:
>>>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>>>
>>>>> One could argue that I should not worry about all those obsolete
>>>>> revisions, but I do for a couple of reasons:
>>>>
>>>> Yes, I'm pretty sure that will be the message going forward: "Don't
>>>> worry, Mercurial has your back! It will save older versions of your
>>>> commits and you can recover them".
>>>>
>>>> Saving too much should be seen as a good thing, at least initially.
>>>
>>> I agree.
>>>
>>> I am not questioning that the default behavior of evolve should be to
>>> keep every obsolete revision. I'm just saying that sometimes it can
>>> make sense to want to _manually_ get rid of a _local_ obsolete
>>> revision.
>>>
>>>>> - I rarely need to go back to my obsolete history, but when I do it is
>>>>> usually because I need to go back to a previous state of my code. In
>>>>> those cases I need to have a look at the hidden, obsolete revisions.
>>>>> Having all those trivial amends mixed with the actual useful revisions
>>>>> makes it harder to find the revision I want.
>>>>
>>>> That does make sense to me and I think the answer is to let log viewers
>>>> color/hide such precursor commits. See below.
>>>
>>> At work I have a repo were I use amend quite a bit. The resulting DAG
>>> (including the obsolete revisions) can get complex very quickly. A non
>>> negligible subset of the obsolete revisions are just commit message
>>> fixes. Getting rid of those makes the obsolete DAG simpler. Sometimes
>>> I use qrefresh to avoid them and I sometimes use strip to get rid of
>>> them (however I'm not sure that does the right thing in terms of the
>>> obsolescence markers). Having the log viewer hide them somehow could
>>> be a better solution.
>>>
>>>>> - I believe that obsolete revisions that only edit the revision
>>>>> metadata are "as big" as any other revisions (since I am not using
>>>>> generaldelta). I know I should not worry about that but for some
>>>>> reason I do.
>>>>
>>>> If that's the case, then that's clearly a problem that we should solve
>>>> on a different level -- you should not spend your time micromanaging
>>>> this by selecting between different history editing tools :)
>>>
>>> I agree that perhaps I should not care much about this. However I do
>>> like to go back to obsolete changesets from time to time, to look at
>>> some previous state of my code (that is one of the big user stories of
>>> evolve, isn't it?). When I do so having a simpler obsolete history
>>> helps a lot. The fact that currently evolve creates a bunch of
>>> "temporary amend commits" that are left behind does not help in
>>> keeping a simple obsolete DAG.
>>>
>>> Keeping that DAG simpler is one of the two main reasons why I still
>>> prefer to do QRefresh for simple fixes. The other is that commit
>>> --amend is _really_ painful to use when you want to remove a file from
>>> a revision (while qrefresh makes that trivial).
>>
>> For removing a file, there is 'hg uncommit FILE'.
>
> I don't use hg uncommit because THG does not support it (yet). For now
> it is much easier to import to MQ and qrefresh when I want to remove a
> file from a commit.
>
>> For your other points, I think you are going about this the wrong
>> way. As Martin hinted at, the problem is how to better display hidden
>> changesets in a way that makes it easier to navigate back to an older
>> revision. This doesn't necessitate the need for stripping obsolete
>> markers.
>
> I did suggest that being able to see which revisions amend only the
> metadata would improve things quite a lot, so I guess that we agree,
> more or less. That being said I don't see what is wrong with wanting
> to be able to get rid of a local obsolete revision.

What is wrong with it is that it's extremely dangerous and
non-DVCS-like. There hasn't been a valid reason presented to justify
stripping obsolete markers. Improving the DAG legibility is worthwhile
but can and should be done without even thinking about the need to strip
obsolete markers.