monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathan Myers
Subject: [Monotone-devel] Re: user-friendly hash formats, redux
Date: Fri, 3 Dec 2004 22:20:13 -0800
User-agent: Mutt/1.3.28i

On Sat, Dec 04, 2004 at 12:16:08AM -0500, graydon hoare wrote:
> Nathan Myers wrote:
> 
> >It's a little bit longer than the hex, but not badly so.  ...  Four 
> >words gives you forty bits, extremely unlikely to collide, yet are 
> >easier to recall (or say) than six hex digits that yield only 24 
> >bits.  Although the choice of formats could be a command-line or 
> >configuration option, I don't see any real reason to retain the hex 
> >format.
> 
> there's actually an old branch njs put together to do this with a format 
> called "bibblebabble".. the idea keeps coming up, but I've never really 
> felt it helped much. it adds another way of referring to things, and it 
> doesn't bring you any improvement in order or meaning, just helps with 
> rememberability. I don't know how much we need to remember them, rather 
> than just enter them, and copy-and-paste works just as well with either.

Bibblebabble, IIRC, wasn't actual words.  

What need is there to use, or even _have_, a hex representation at 
all, if a more human-compatible format works better?  To me, to need 
to copy-and-paste is a nuisance.  I'd much rather type two or three
three-letter words than touch the mouse or even the numeric row.  
Three words gives me 30 bits, which would take eight hex digits to 
match.  Few can remember eight hex digits even long enough to say 
or type, but three words is easy for anyone.  You might not find 
yourself naming revisions over the phone, but many of the rest of us 
certainly will.

The reason this keeps coming up is that the hex codes are probably the 
most immediately intimidating thing about Monotone.  Those terrifying 
blocks of hex codes probably keep more people away from Monotone than 
any sort of unfamiliarity with its concepts, or any lack of features.  

I would also suggest inserting a period after the word where, at the
moment, the revision is uniquely identified in the current state of the
repository.  I expect it would usually appear after the second word
even in big repositories.

Nathan Myers
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]