Re: improving `mtn status`

On 12/10/14 15:10, Markus Wanner wrote:
> 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
Sounds reasonable to me. I could understand the `would be' revision id 
causing confusion, it never has with me but I can see how it could. As 
for the last point that too has irritated me slightly on occasion.

Tony.

_______________________________________________
Monotone-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/monotone-devel