Help designing the evolve UI

[Angel Ezquerra]

On Fri, Apr 18, 2014 at 12:05 AM, Jordi Gutiérrez Hermoso
<jordigh at octave.org> wrote:
> On Thu, 2014-04-17 at 16:50 +0200, Aurélien Campéas wrote:
>
>> Stripping obsolescence markers is useful for the same reason strip
>> is useful (and to be used wisely & sparingly).
>>
>> Now, if there are theoretical or practical objections to that,
>> I'd like to know them. I'm not, however, interested in anathems.
>
> The problem is that stripping obsolescence markers is really the exact
> same situation as stripping csets: you have to do it locally and then
> check if you have to do it in any remote repo. Then you're in the same
> situation we have now with stripping.
>
> So why add an obsolescence concept if we already have the same
> situation with plain stripping?
>
> In order for Evolve to work, it *has* to be purely append-only. It
> cannot delete *any* information -- it can only add information. And
> this is ok: the phases indicate when this added information is safe
> and when it is not.

To give a counter argument to this, I sometimes find it annoying to
use amend with the evolve extension enabled _because_ I know that the
amend I'm doing is something so trivial that I would not want to
record the previous state. This happens mostly when I just want to fix
a typo on the commit message. In those cases I find myself importing
to MQ and using qrefresh rather than amend, just to avoid the extra
hidden revisions which make my hidden history more complex.

One could argue that I should not worry about all those obsolete
revisions, but I do for a couple of reasons:
- 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.
- 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.
- There are "mistakes" and then there are "Mistakes". If I make a
first version of a patch and then I get some review comments and point
me on a different directions it is nice to have the old version around
just in case. But if I mispeled zomething on de comit mezage... I'd
rather forget about that :->

I guess that some of this would not bother me as much if there was an
easy way to tell if an amend revision just amended the revision
metadata. We could then mark these types of revisions differently on
the DAG...

Anyway, perhaps it is a bit silly of me to worry about this, but I
thought it was worth pointing this out so that you can see that it may
bother some (or at least one) users to have all their mistakes
recorded for posterity, even if no one else cares about them.


> If you really need to somehow unobsolete some commit that exists in a
> location other than the local repo then just strip that commit along
> with its obsolete marker and pull again. Serves you right that this is
> cumbersome: it's not something you should do, and the only case in
> which it matters to get the exact same hash is when the hash exists in
> a location other than locally.
>
>> > The feature you miss is a better story to revive changesets.
>> >
>>
>> I know how to use "hg touch" to revive changesets. This is good
>> enough as far as I'm concerned.
>
> I think `hg touch` should be renamed to `hg restore` and should be a
> no-op on non-obsolete csets (currently it also works on non-obsolete
> csets, which is probably why it's called "touch"). It should basically
> become the "restore from backup" command, a better interface than
> git's reflog.

I think hg touch is possibly the most confusing command in the evolve
toolset. "Restoring" a revision by creating a new one is...
surprising. The command name is possibly accurate considering what it
does in practice, but it is confusing (IMHO) if you consider what its
actual purpose is (i.e. to unobsolete an obsolete revision).

Cheers,

Angel