[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] 0.48 rants

From: Markus Wanner
Subject: Re: [Monotone-devel] 0.48 rants
Date: Sat, 17 Jul 2010 14:31:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100619 Icedove/3.0.5


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

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]