On Sat, Jul 17, 2010 at 6:31 AM, Markus Wanner
<address@hidden> wrote:
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.
Early on, uncommitted revisions were displayed with "(uncommitted)" on the Revision: line. This got lost somewhere along the way.
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.
The case of a workspace with no changes is definitely bad right now. The workspace revision is shown as the Parent: and a new Revision: id is generated. At the very least in this case Revision: should probably be the revision of the workspace.
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.
We could also display things printed right to left or upside down to achieve the same thing. I don't think that would be very good though, it's just another random format of the same information. When status says "no changes" at the bottom the revision id should certainly be the id of the workspace which is not the case at the moment.
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).
Recall the "oops I forgot to specify a new --branch option" case which is what got all of this started or are you specifically talking about the status output?
Cheers,
Derek