improving `mtn status`

Markus Wanner <[email protected]> Sun, 12 Oct 2014 16:10:37 +0200
Newsgroups	gmane.comp.version-control.monotone.devel
Message-ID	<[email protected]>
Hi,

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'm using a mtn from that branch for a while now and am pretty content
with that new status output. Please give it a try as well; I'd
appreciate feedback. In the following, I'm trying to cover the important
changes and the reasoning behind.


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.


The current `mtn status` created a hypothetical revision and prints the
resulting rev id. Often enough, I created copy-pasta from that and was
left wondering why the rev didn't exist. I didn't *ever* need to know
what revid a commit *would* create. Therefore, I consider that
information not just useless, but harmful.


Another message that constantly annoyed me is: "THIS REVISION WILL
CREATE DIVERGENCE". Firstly, I perceive it as impolite yelling. And
second, a lot of the time that message is flat out wrong. Some common
scenarios:

 * if you're just inspecting an old revision, it always appears. Even
   though you have no intention of ever committing on top of that rev.

 * it even appears if there's no single file changed and it's
   impossible to commit such a revision.

 * the message appears in a freshly setup workspace. While technically
   correct (there usually are other descendents from the null rev),
   it clearly is the users intention to start a new project.

Bottom line: It usually makes me want to yell back: "NO! THERE IS NO
SUCH REVISION AND IT WON'T EVER CREATE DIVERGENCE".

However, there's potentially useful information that can be gathered
from that line: It is telling that there is at least one newer revision
and you might want to `mtn up`. The proposed `mtn status` tells you just
that (and even gives a rough estimate on how many revs you can advance).
I consider that more to the point and much less offensive.

Another point: the user might intend to create divergence - no reason
for such a bold warning. That's all fine and monotone is well designed
to deal with divergence.


Some similar points can be made about the message: "THIS REVISION WILL
CREATE A NEW BRANCH": There simply is no such revision, yet. (Again, it
might not even be possible to create it.) But it's usually more correct
in that it simply outlines the current user's intention. I personally
still prefer an informative style, rather than having that info yelled
back at me.

Interestingly, it hides the "DIVERGENCE" message. Granted, given the
user wants to create a new branch, he kind of intends to diverge.
However, the information that the parent revision could be upgraded
(along the old branch) may still be useful. Maybe the users wants to
`mtn up` again, before branching?


So far, `mtn status` only ever listed one branch. However, if the parent
revision is in multiple branches, I consider that useful status
information. Clearly, the current branch - where a commit would go to -
still needs to be shown. The proposed new `mtn status` tries to do that.


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.


The nvm.revamp-status branch addresses these issues. It doesn't quite
pass all tests, yet. And there still are minor issues and other UI
issues that I'd like to address, eventually. However, I think it's a
good point in time to ask for feedback, so please have a look and
provide feedback regarding `mtn status`.

Regards

Markus Wanner

_______________________________________________
Monotone-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
signature.asc (application/pgp-signature, 1.5 KB)