Help designing the evolve UI

[Sean Farley]

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

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.