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

[Stephen Leake]

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.

Thanks for working on mtn!

I never use 'mtn status', except to check that the Emacs DVC front end
isn't lying to me :).

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

But the changes you describe sound reasonable.

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

> The fundamental conceptual mismatch is that the current `mtn status`
> basically answers the question: "what would happen, if I tried to commit
> this, now?" Where as I expect it to provide more general information
> about the status of my working tree. Oftentimes without any intention of
> committing.

+1

> 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; that annoys me, since 'update' is
very similar to 'revert'! Perhaps we need an 'update --revert', meaning
"revert as needed, then update".

-- 
-- Stephe