[Monotone-devel] Re: user-friendly hash formats, redux

[Bruce Stephens]

Nathan Myers <address@hidden> writes:

[...]

> +n/-n is not very flexible.  Consider, instead, suffixes that I'll
> represent symbolically as .p and .c, for parent and child.  Then, 
> -2 looks like ".p.p" and +2, ".c.c".  On a merge, .p.p becomes 
> ambiguous, but you can decorate it with, e.g., .pl.p or .p.pr, 
> with "l" and "r" for left and right.  Maybe instead of left/right, 
> you just specify one or two digits of the correct node's hash.  Or, 
> maybe when you did the merge, you had to say which one was "left".  
> Or maybe monotone assigns it at random, and tells you which is 
> which when you look at the graph.  Or, maybe left is always the 
> older one.  Or maybe most of the above, with different annotations.

Left and right don't currently mean anything, do they?  (They don't
mean anything to me, so I'd find that confusing.)

> Suffixes naturally support more interesting paths just as well, such
> as .p.cr for the right-child of my parent (presuming I'm the left
> child).  Where might only be a left or right parent, a node might
> have N children, so left/right is not necessarily meaningful for
> them, and a hash fragment or tag might be needed to disambiguate.

And that thinking ought to naturally lead us back to selectors, I
think.  My guess is that often I'd want to distinguish a fork by
author, for example.

So I think this is another use for selectors, or maybe it's an
extension.  I don't know what a good syntax would be.  Something like:

            njs/2004-12-09/ba+3p/njs/7c

Which would expand to 7c5e7b05d145c3bd2b908b52be7230940fe98c32.  So
the first selector selects a unique revision, and then you add a
modifier which says to look for a parent of a parent of a parent of
that (which is ambiguous, assuming I'm reading the graph correctly
there's paths from c4b86ffe3e12c76728b566b... and
70dbbd66e5fa4cd39aa28f83dfeb8).

Actually that looks nasty, and it's a bit unpleasant doing that kind
of thing in SQL.  It would probably be OK (and probably more
comprehensible) to limit it to one level at a time, so you'd write the
above selector as:

            njs/2004-12-09/ba+p+p/njs+p

On the other hand, probably I'd never want to do that: I could only
work that out by using monotone-viz, and if I've done that I may as
well use the hash.

I can't help feeling there's something missing in the command line
monotone if I need to use monotone-viz to see what's going on.  Partly
I'm missing "tla revisions [--summary] [--date]" and things.
"monotone log" seems much too verbose.  

Any chance of somehow encouraging or requiring a one-line summary of
each change, that could then be used to show history more compactly?