[PATCH RFC] reflog: adds a reflog extension

[Durham Goode]

On 10/6/14, 1:51 PM, Jordi Gutiérrez Hermoso wrote:
> On Mon, 2014-10-06 at 13:52 -0500, Matt Mackall wrote:
>> On Mon, 2014-10-06 at 14:19 -0400, Jordi Gutiérrez Hermoso wrote:
>>> On Mon, 2014-10-06 at 10:42 -0700, Durham Goode wrote:
>>>> On 10/5/14, 6:54 PM, Jordi Gutiérrez Hermoso wrote:
>>>>> On Wed, 2014-10-01 at 18:45 -0700, Durham Goode wrote:
>>>>>> # HG changeset patch
>>>>>> # User Durham Goode <durham at fb.com>
>>>>>> # Date 1412200597 25200
>>>>>> #      Wed Oct 01 14:56:37 2014 -0700
>>>>>> # Node ID 942be96848993cf7ab5ed529db9c1f39c6d43c30
>>>>>> # Parent  939ce500c92a3dcc0e10815242361ff70a6fcae9
>>>>>> reflog: adds a reflog extension
>>>>>>
>>>>> I'm a little bothered by the UI. Like you said in a later email, the
>>>>> goal here is to undo bookmark or pwd motions. The fact that the
>>>>> information to undo is in a log should be mostly irrelevant for the
>>>>> user. In that case, I propose that what you're currently calling
>>>>> `reflog` should be something like `debugstatelog` and the `bookmark`
>>>>> and `update` commands should use this statelog to grow --undo and
>>>>> possibly --redo flags, e.g.
>>>>>
>>>>>       # Move bookmark master to whatever state it was before its current
>>>>>       # state
>>>>>       hg bookmark master --undo
>>>>>
>>>>>       # Move whatever was the last moved bookmark to whatever its
>>>>>       # previous state was
>>>>>       hg bookmark --undo
>>>>>
>>>>>       # Move dirstate and active bookmark to whatever they were before
>>>>>       # the last time an `update` command was invoked
>>>>>       hg update --undo
>>>>>
>>>>> Can we use your extension or perhaps blackbox to also provide an
>>>>> --undo flag for `update`? Should your extension be rolled into
>>>>> blackbox?
>>>>>
>>>>>
>>>> Undo and redo have significant connotations (and large expectations) for
>>>> a user, so I don't want to use that terminology.
>>> I think it's expected to expect that `hg bookmark --undo` only moves
>>> or recreates bookmarks, which is the same thing that `hg bookmark`
>>> does.
>> If you think that, you are clearly not supporting a thousand ex-Git
>> users who are mis-applying their vague understanding of Git branches to
>> Mercurial bookmarks.
> If this is about appeasing git users, then I suppose giving hg a git
> reflog command and exactly a git reflog command is all we can hope
> for.
It’s about building a nice, easy road for people to follow to the 
greener pastures of changeset evolution. Part of that is making 
migration easy, and reflog is a good starting point since it's an 
already well defined concept (albeit with a rough UI).  We have plans 
for a 'hg rewind' command that will allow the undo-esque behavior you're 
talking about in a more friendly way.