[PATCH 4 of 4 V2] obsolete: allow cycles

Sean Farley sean at farley.io
Wed Mar 22 16:59:22 EDT 2017


Jun Wu <quark at fb.com> writes:

> Excerpts from Sean Farley's message of 2017-03-22 13:18:29 -0700:
>> Heh, yes, that made me chuckle. I understand that *you* need this.
>
> I'd argue *most people* wants this. See below.
>
>> But that's the thing. I'm not taking "inhibit" into consideration
>> because inhibit isn't a common workflow. It's completely a facebook
>> thing.
>
> If you could look a bit ahead, commends like "unamend", "unstrip",
> "unabsorb" and "undo" in general will basically need the stuff.
>
> I guess Bitbucket don't have the data about how much demand users want those
> commands, since they are power-user only and need complex manual setup. But
> we ship commands like "unamend" and friends we have data and feedback that
> those commands are great and in high demand.

Evolve doesn't even have the terminology finished. What you are
basing this on is, in my opinion, a very advanced and Facebook specific
workflow.

> You may argue it's still Facebook-specific. But I don't see why "unamend"
> has any fb-specific bit. The demand of those commands is universal.
>  
>> > this approach not only
>> > simplifies things *greatly*, it also handles the case much cleanly and with
>> > much more confidence. If we count the removal lines in inhibit and all kinds
>> > of code supporting it, I'm sure there will be much more deleted lines than
>> > added. That is a decent clean-up. How could you define it as
>> > "over-engineering" ?
>> 
>> I think that's a discussion for another time.
>> 
>> > If you had good points indicating that "inhibit" is a reasonable permanent
>> > solution and provides a good user experience, then I'd be happy to drop the
>> > series. If you do so, be prepared with questions about all kinds of corner
>> > cases.
>> >
>> > By the way, I'm not sure if you have noticed that "inhibit" was recently
>> > moved to a directory called "hack/" in mutable-history.
>> 
>> Yes, things in evolve are still baking. I don't see the need to rush obs
>> cycles into core based on that, though.
>
> Shall we have "unamend", "unrebase", "unhistedit" and "undo" ready, please
> do not use them as you don't need them.

But that's part of the problem: all the edge cases mentioned here will
affect normal use of obs markers. Why not put this in an extension for
now? I don't see how this is more important than fixing terminology /
error messages / UI / UX / etc etc etc.

That being said, my questions weren't really for you. I am not a leader
here. My questions are for the steering committee and the rest of the
community.


More information about the Mercurial-devel mailing list