[PATCH RFC] reflog: adds a reflog extension

[Jordi Gutiérrez Hermoso]

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. Same for `hg update`, all it does is update to a different
revision. What user expectations are you afraid of?

> Also, in vanilla hg there is no way to undo many things without
> digging through the backup bundles, so I don't think the log can be
> actionable by default.

I think this is an acceptable compromise. "Cannot find revision X,
trying revision Y instead", where Y is the earliest revision in the
log that was found.

What I am trying to get at here is that I think we can do better than
`git reflog`. Or perhaps now that everyone is used to `git reflog`,
it's the gold standard and we should just duplicate it exactly. Do you
think we can do any better than `git reflog`?

> I'm not sure about putting it in blackbox. Blackbox is about
> recording a series of actions in the repo. The 'ref/book/thing-log'
> is about recording previous states of the repository.

Aren't these just two ways to record the same information?

- Jordi G. H.