Re: [Monotone-devel] 0.48 rants

[Markus Wanner]

Hi,

On 07/14/2010 04:48 PM, Derek Scherger wrote:
> 2. Unify the output from status, commit and log as much as possible
> (perhaps this has gone too far).

That has definitely gone too far. It's no longer possible to 
differentiate between uncommitted 'pseudo' revisions and committed stuff.

I recently shot myself in the foot several times by copy'n'pasting the 
'revision id' from 'mtn status' only to figure with the next command, 
that such a revision id doesn't exist. Took me some thinking cycles to 
understand the problem.

IMO there's absolutely no point in presenting the user a revision id 
that doesn't exits. Or what's the use case for 'if committed as is, this 
would result in revid deadbeef'. Realizing, that I don't like deadbeefs 
and have to change to content by a bit or two to get a revid I like better?

> Previously status would display various
> things about the current workspace that included the list of changed
> files, branch information etc. in a completely haphazard (i.e. not like
> log)

Which allowed to easily tell a difference between committed and 
uncommitted stuff.

> way and commit wouldn't display anything.

It told you the newly committed revision id. Which makes sense there, IMO.

> By displaying the
> revision as it will look after it has been committed you get a chance to
> "preview" your commit and fix things you're not happy with.

I fail to see any addition that's worth adding. The branch info has been 
there before, for the date your argument simply doesn't apply (or is 
there a 'mtn status --date'?) and the author usually doesn't change that 
much. (And if you want to commit for somebody else, you are mostly well 
aware of the special case).

Regards

Markus