Re: [Monotone-devel] improving `mtn status`

[Markus Wanner]

On 10/18/2014 10:40 PM, Stephen Leake wrote:
> Markus Wanner <address@hidden> writes:
>> it's been a while since the C++11 refactoring, but as promised, here's
>> some actually useful work: I scratched a couple of itches I had with
>> recent monotone's status command and started a branch trying to improve
>> it: net.venge.monotone.revamp-status.

I landed this on nvm .. uhm .. several moons ago.

> So as long as you don't change 'mtn auto inventory', this does not
> affect me.

No changes (intended) for auto inventory.

> One goal might be to make it closer to 'git status', and or 'hg status',
> so people migrating to/from those are comfortable.

I know git a bit, but didn't really try to mimic it. I don't use mercurial.

>> Another naughty example - which I consider a bug - is `mtn status` on a
>> working tree that misses files known to the parent revision (or has
>> mismatches in type - i.e. file vs directory). For example:
>>
>>> mtn: warning: missing file 'm4/stlporthashmap.m4'
>>> mtn: warning: not a file 'Attic/m4'
>>> mtn: warning: expected file 'Attic/m4', but it is a directory.
>>> mtn: warning: missing file 'm4/tr1unorderedmap.m4'
>>> mtn: misuse: 3 missing items; use 'mtn ls missing' to view.
>>> mtn: misuse: To restore consistency, on each missing item run either
>>> mtn: misuse:  'mtn drop ITEM' to remove it permanently, or
>>> mtn: misuse:  'mtn revert ITEM' to restore it.
>>> mtn: misuse: To handle all at once, simply use
>>> mtn: misuse:  'mtn drop --missing' or
>>> mtn: misuse:  'mtn revert --missing'
>>
>> Even though some files are missing, mtn should still be able to give me
>> more elaborate status information - rather than forcing the user to fix
>> these issues, first.
> 
> +1
> 
> This happens on 'mtn update' as well; 

Yes. Unlike status, update is a potentially destructive command. IMO the
best we can do in that case in listing *all* causes that prevent an
update (rather than just the first error).

> that annoys me, since 'update' is
> very similar to 'revert'! Perhaps we need an 'update --revert', meaning
> "revert as needed, then update".

I don't see much benefit over just 'revert then update'. I certainly
wouldn't remember the special argument. :-)

Regards

Markus Wanner