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

[Bruce Stephens]

graydon hoare <address@hidden> writes:

> Bruce Stephens wrote:

[...]

>> 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.

That's what I understood: this is more than just sucking in newcomers,
whatever's implemented ought to offer some benefit to all users.

> 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.

[...]

> 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.

My guess is that (3) is an important part of it: monotone always
prints out a hash, and never something in the right syntax to be a
selector.  Maybe the tutorial could use some examples (currently it
doesn't use hashes, either, although it shows them as output).

It's not obvious to me when I'd want to use a selector or a hash (I've
only used them as the result of bugs, so far, where a branch was
unmerged, and I wanted to pick one manifest).  When I'm using other
systems, I've used revision selectors (or whatever form) to look at
differences in files, logs, or sometimes to deliberately check out
older versions of the code (because the current one is broken).

Perhaps some tutorial examples showing selectors in use would be
helpful?

[...]

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

Those might work.  Couldn't they be made part of the selector, though?

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

I'd have though just printing out all three would do (if you can fit a
SHA1 hash, then the other two won't take up significant extra space).