Help designing the evolve UI

Aurélien Campéas aurelien.campeas at logilab.fr
Fri Apr 18 03:56:53 CDT 2014


On 18/04/2014 00:05, Jordi Gutiérrez Hermoso 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.

Yes. This is assumed. I gave a reasonnable use case. These things
do happen.

> 
> So why add an obsolescence concept if we already have the same
> situation with plain stripping?

The obsolescence concept is about sharing rewritten histories.

The strip concept (if it were not important, why has "strip" been
moved from mq to its own extension ?) is a useful tool to repair
locally broken stuff.

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

This is well understood.

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

I can well strip the unwanted commit but not the unwanted obsolescence
marker. Which is what I'm talking about.

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

It could be spelt "hg resurrect" ....

Regards,
Aurélien.






More information about the Mercurial-devel mailing list