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

[graydon hoare]

Bruce Stephens wrote:
> Nathan Myers <address@hidden> writes:
>
> > Aliases are good too.  To invent good aliases automatically would be
> > nice.  Short, sayable and rememberable (if not "memorable") hash
> > formats, though, are certainly easier to implement.  Once people
> > stop being spooked by the tutorial, we'll have a better chance of
> > finding somebody to implement lots of nice features.
>
> It doesn't sound like Graydon wants to introduce features simply to
> avoid frightening potential users.  

no, that's not true. I'm quite willing to change monotone to avoid 
frightening off users. software is really all about human factors, at 
some level or another; computers would be happy to sit there idling and 
accepting no input from us.

what I'm unwilling to do is make deep changes without giving a fair bit 
of thought to what we're trying to accomplish. so I'm glad we're 
discussing. I don't enjoy someone throwing down the gauntlet and 
deciding there is One True Way of doing things. there are usually many ways.

I see there as being 3 issues to decide:

1. whether hashes-as-identifiers are acceptable, from a human factors
   perspective, as an *implementation* technique alone. eg. is it
   acceptable for debug logs and whatnot to contain hashes, and for
   some parts of the manual to describe hashes in passing, if they are
   sufficiently rare in user input and output?

2. whether the UI accepts something which is more user-friendly to
   input.

3. whether the UI always (or mostly) prints out the more user-frendly
   things when describing revisions, files, etc.

so far I believe #1 is still ok. I think it's ok to use hashes under the 
covers. I think for someone who cares enough to *look* under the covers, 
they're comfortable enough with the issues to find hashes inoffensive, 
even desirable (I've outlined why I feel so). if that's wrong, we have 
more work to do. but I think it's ok. if you want to discuss this one 
further it's important to say so now, because it's a much deeper amount 
of surgery to change.

I think #3 should probably be enhanced if we decide anything for #2: we 
should make the log format, the ancestry graph, the status command, etc. 
print out whatever format is friendlier for accepting. this would mean 
that the status command isn't the *exact* contents of a changeset as 
stored within a revision, in the repository. that was a nice 
coincidence, but if it can't be maintained I can live with it.

for #2, I already made the UI accept something more user-friendly than 
hashes, but it's apparantly not enough. the fact that people are still 
bothered by it is evidence that it's not enough. I accept that. it's a 
data point, you can't really argue with data. I keep having people say it.

interpreting it is tricky. it might be not enough for a few reasons:

  - perhaps entering "2004-08-01T13:44:57" is too cumbersome a way to
    enter dates (or not very memorable). but I think that's not the only
    point: people's date-memory is fuzzy; it's very rare to actually
    refer to a *specific* CVS version by date, just a ballpark. if I
    say "I was doing something last friday at 8:51 pm", you might
    be able to stash that as little more than "er .. late last week"
    in your mind, which makes the event ambiguous with everything
    else around that time.

  - perhaps bibblebabble or nathan's dictionary approach would help.
    I've resisted this because I don't feel like it adds much
    *meaning* to identifiers; I think people would in fact find it
    easier to look at monotone as some crazy moon-man system if it
    insisted on calling your versions "dog-wall-stink-egg" or
    "fwee-bazoo-frump-gorf". at least 0x9f798f98ea is somewhat clearly
    a number, albeit an unfriendly one.

  - perhaps authors and dates, or "the things we already have around
    as certs", are less desirable than "sequence numbers". VC has a long
    history of using sequence numbers. I posted a couple days ago a
    proposal -- quite honestly -- for assigning CVS-style "local" x.y.z
    sequence numbers, which is relatively easy to do now that we have a
    fixed DAG-shaped revision graph. I'm perfectly willing to implement
    that, if it would help.

  - another local sequential system might involve keeping a sequence
    number for each author, sorted by date, such that the numbers go

      "derek-10", "graydon-12", "matt-72", "joel-13", "derek-11"

    (this would have an interesting social effect of automatically
     "ranking" contributors by commit volume, such that I would be
     committing "graydon-206", just after "njs-38". also the numbers
     would be quasi-stable and quasi-global for teams which shared
     complete history.)

I'm willing to completely toss out the selector stuff we have now if 
nobody's using it. it's an experiment. I can accept failed experiments, 
and we know the command-line is in need of an overhaul anyways. here is 
a concrete proposal: what would happen if the command line accepted 
revisions in any of 3 forms:

   --hash   or -h  <id>                global hash identifier
   --seq    or -s  <author>-<seq>      local sequence numbers
   --rev    or -r  <x>.<y>.<z>...      local revision numbers

and we ask a hook for your preferences as far as which to print out 
(possibly all three) when listing logs, status, etc.

-graydon