[PATCH 4 of 5 evolve-ext] strip: add the option for wrapping the strip command

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Mar 20 14:44:05 CDT 2015



On 03/20/2015 11:25 AM, Durham Goode wrote:
>
>
> On 3/20/15 11:12 AM, Harvey Chapman wrote:
>>> On Mar 20, 2015, at 1:32 PM, Durham Goode <durham at fb.com> wrote:
>>> We're migrating our existing user's onto evolve and in their minds
>>> 'strip' is how they make commits go away.  They don't care if they're
>>> actually stripped, or just hidden, or sent to the moon.  So from a
>>> user experience stand point, the first step of deploying evolve is
>>> doing it in a way that changes as little of the UI as possible, then
>>> we'll introduce the new concepts piece by piece.
>> Why not…
>>
>> $ hg strip options
>> The strip command is no more. Perhaps you meant:
>> hg prune equivalent options
>> $
>>
>> That should retrain your users in a hurry while giving them a quick
>> copy/paste solution. It also clues them into the fact that the method
>> of making commits go away may have changed (if they’re interested).
> A few reasons:
>
> 1) with thousands of users, even the slightest UI change always
> generates support load (and this isn't really slight)
> 2) doing this would require that we come to some final design on the
> prune command, which we're not ready for
> 3) automation (much of which our team doesn't own) already uses strip,
> so we're not going to bother migrating them yet since it's a lot of work
> with no real benefit
>
> There are of course rebuttals to all those points, but the big picture
> is that our users are having a tough time with recovering commits in
> mercurial (bundles are not a great experience), and this is the shortest
> path to solving that problem and getting evolve deployed.  Then we can
> iterate from there.

I'm +1 on that. The strip change is not suitable for core-ish behavior 
and will most probably not make it in the final UI. But that is why it 
is behind a config option, turned off by default. In some environment, 
like the fb one were user and tool have been heavily taught about `hg 
strip` we need a more smooth transition. Moving from actual strip to 
hidden changeset will be a good enough jump.

Having this modificiation to strip in evolve makes it much more easy to 
use the `hg prune` code base and will focus the dev effort toward 
improving `hg prune`.

So, do not panic, this is not a long term UI direction, just an useful 
helper to get more user and effort toward building the right UI.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list