[PATCH RFC] reflog: adds a reflog extension

Gregory Szorc gregory.szorc at gmail.com
Wed Oct 1 21:56:47 CDT 2014


On 10/1/14 6:45 PM, 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
>
> This adds an extension that tracks the locations of the working copy and
> bookmarks over time. It's still a proof of concept, but I wanted to throw
> it out there to start the bike shedding early (like finding a better name
> than 'reflog'). We're close enough to the release that I don't think it should
> go in before that.
>
> Running `hg reflog` by default shows the previous locations of the working
> copy (most recent first).
>
> ~/myrepo> hg reflog
> 35a5fcfee452 > rebase -d master
> 32eee5e2d406 > up .^
> b5d6dab4f900 > up foo -C
>
> Specifying a bookmark name shows the locations of that bookmark over time.
>
> ~/myrepo> hg reflog foo
> d1a696044ec0 > rebase -d master
> 35a5fcfee452 > rebase -d master
> 32eee5e2d406 > book foo -f
>
> --date and --user flags exist to show more information about each entry.
>
> ~/myrepo> hg reflog foo --user --date
> d1a696044ec0 durham 2014-10-01 18:32:14 > rebase -d master
> 35a5fcfee452 durham 2014-10-01 17:28:54 > rebase -d master
> 32eee5e2d406 durham 2014-10-01 17:28:30 > book foo -f
>
> It's currently stored as a single .hg/reflog file that is append only. Each
> entry can store an arbitrary number of hashes (like storing 2 hashes for a merge
> state working copy), which means we could also potentially use this to track
> heads in branches as well.

Very nice!

Do you think it's worth adding "local/working" terminology to help 
distinguish it from the inevitable support for "remote reflogs" or 
"store reflogs?"

FWIW, I'm rewriting Mozilla's reflog implementation as an extension and 
adding support for data transfer via the wire protocol. However, I'm 
currently aiming for backwards compatibility (SQLite - which I know 
won't fly upstream) and only support for a single remote (again, 
optimized for our current server-side use). However, I'd eventually like 
to integrate client-side aggregation of reflogs from multiple remotes. I 
know it's scope bloat, but if this reflog extension becomes officialish, 
I'd like to see a path to supporting store and remote reflogs in the 
same extension.

Gregory


More information about the Mercurial-devel mailing list