Re: [Monotone-devel] status --brief

[Nathaniel Smith]

On Sat, Oct 01, 2005 at 03:14:43PM -0700, Howard Spindel wrote:
> Since monotone is completely based on the SHA1 keys and exposes them 
> to the end user, using monotone successfully does depend on learning 
> about them.  Having keys printed on all operations by default is, I 
> think, a good thing.  It certainly helped me, as a rank beginner with 
> monotone, get used to them and see how monotone uses them.

Hmm.  Current status output in a working directory with one file
edited looks like:

  $ monotone status
  
  new_manifest [a575968a67eaed92db9cd60904d4489b62a06381]
  
  old_revision [0eeeb4e965391e033164b755dd9549d8a777c55f]
  old_manifest [d5bbe42b2a897105944510e3b1cee349861cf7ce]
  
  patch "ChangeLog"
   from [4da55323c6f152dfe2c5f92498c70d02902769bc]
     to [ad67b8bca0dab5827d046cf7d748400e3e930385]
  
  $ 

While the --brief version of the same is:

  $ monotone status --brief
  patched ChangeLog
  $ 

Of all the hashes in the non-brief version, the only one the user
should ever have to deal with is the old_revision hash; the rest are
important internally, but should never be needed in the UI.  This
suggests to me that perhaps the --brief output should include this
information too, like:

  $ monotone status --brief
  base revision is 0eeeb4e965391e033164b755dd9549d8a777c55f
  patched ChangeLog
  $ 

What do you think of this format?

Compared to the current default, this has the advantage that it only
includes the _relevant_ chewy blobs of hex, so as not to distract and
scare the user with all the irrelevant ones (not to mention wasting
their time).

Taking a different point of view, it has the *dis*advantage that it
hides more -- it's still perfectly easy to get at the same information
with commands like "automate get_revision", but it's not throwing so
many hashes in your face all the time (and thus getting you acclimated
to the monotonic "snapshots and hex blobs" sort of environment).  It
also means that users won't be exposed to monotone's raw internal
formats in normal usage, and that makes everything more mysterious and
magical than it needs to be.

(Well, I guess they still see the header to 'diff', and the hints on
what changed that are included in the commit message editor -- commit
message hints should match 'status', I think, but diff's are perhaps a
little different, since it would be nice if they're parseable...)

-- Nathaniel

-- 
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
  -- Letter to the Editor, The Times, September 2000