Re: [Monotone-devel] Some smaller issues, Nico's TODO

[Derek Scherger]

Nico -telmich- Schottelius wrote:
> 2. Can we change the output of the certs command?
>    I think the "old" way is rather hard to read.
>    Instead of
>
> ------------ snip ---------
> Key   : address@hidden
> Sig   : ok
> Name  : author
> Value : address@hidden
> ------------ snap ---------
>
> I would suggest
>
> ------------ snip ---------
> Key   : address@hidden [SIG: ok]
> Author: address@hidden
> ------------ snap ---------

I was playing around with this the other day and I ended up with the following which does 
involve somewhat long output lines. I'm listing version, signing key, cert name, cert 
value and cert status on one line.  In the changelog and probably comment cases I'm 
listing the value on the following line.

The leading version is only relevant because I was playing with listing certs on all 
versions matching some selector which I thought might also be interesting.

It might not be a bad thing to drop the sig status (ok) unless there is some problem with 
the sig in which case elaborating on the problem might be good.

$ ./monotone ls certs a4a
monotone: expanded selector 'a4a' -> 'i:a4a'
monotone: expanding selection 'a4a'
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden ancestor 
0bdd9e81ba0c190624046c50993c1a860493a634 ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden ancestor 
8862b8549462c69fa8042ce3e147eadab3084e2f ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden author       
address@hidden ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden branch       
net.venge.monotone ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden changelog ok
-----------------------------------------------------------------
2004-07-31  graydon hoare  <address@hidden>

        * AUTHORS: Mention Richard Levitte.
        * Makefile.am: Remove nonce stuff.
        * NEWS: Describe changes from last release.
        * cert.cc (cert_manifest_testresult): Teach about other ways
        of writing a boolean value.
        * commands.cc (disapprove): Temporarily disable.
        (approve): Certify second manifest in branch.
        (commit): Don't commit when no change.
        (debug): Rename to "db execute".
        (serve): Require passphrase on startup.
        (bump): Remove command.
        (ls keys): Handle no keys.
        * configure.ac: Bump version number.
        * keys.cc (get_passphrase): Reject empty passphrase nicely,
        from user and from hook.
        * lua.{cc,hh} (hook_get_sorter): Dead code, remove.
        * main.cc (main_with_many_flavours_of_exception): s/char/int/.
        * monotone.cc (OPT_DUMP): New option.
        (OPT_VERBOSE): Rename as OPT_DEBUG.
        * monotone.{texi,1}: Document changes, s/rdiff/xdelta/.
        * nonce.{cc,hh}: Drop.
        * sanity.hh (sanity::filename): New field.
        * sanity.cc (dump_buffer): Dump to file or be silent.
        * testsuite.at (persist_phrase_ok): Define as true.
        * tests/t_null.at: Adjust for new option names.
        * unit_tests.cc: Set debug, not verbose.

-----------------------------------------------------------------
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden changelog    propagate of 
0bdd9e81ba0c190624046c50993c1a860493a634 and a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c from 
branch 'net.venge.monotone.win32' to 'net.venge.monotone' ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden date 
2004-08-01T00:02:57 ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden date 
2004-08-01T05:48:30 ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden rename       <binary 
data> ok
a4a197a9ad2f14ee2e4aee4ba8e5bf7f483f731c address@hidden rename       <binary 
data> ok

> 4. When using monotone log / commit I would like to include
>    the changes made by monotone:
>
> ------------ snip ---------
> MT:   move indent_script
> MT:     to scripts/indent_script
> ------------ snap ---------
>
>    What do you think of including the lines into the output of
>    log?

I hadn't noticed they were missing actually... this does make me think of something else 
too. I was wondering whether diffs should list file specific summary info before each file 
diff in addition to listing the full summary at the top. When looking over diffs I seem to 
find myself jumping back to the top at times to see why some file appears in the diff.

> Just some thoughts,

Ditto.

--
Cheers,
Derek