[PATCH 4 of 4 V2] obsolete: allow cycles

[Jun Wu]

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.

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.