improving `mtn status`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

improving `mtn status`

Markus Wanner-2
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: improving `mtn status`

CooSoft Support
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
[hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: improving `mtn status`

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

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

Thanks for working on mtn!

I never use 'mtn status', except to check that the Emacs DVC front end
isn't lying to me :).

So as long as you don't change 'mtn auto inventory', this does not
affect me.

But the changes you describe sound reasonable.

One goal might be to make it closer to 'git status', and or 'hg status',
so people migrating to/from those are comfortable.

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

+1

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

+1

This happens on 'mtn update' as well; that annoys me, since 'update' is
very similar to 'revert'! Perhaps we need an 'update --revert', meaning
"revert as needed, then update".

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: improving `mtn status`

Markus Wanner-2
On 10/18/2014 10:40 PM, Stephen Leake wrote:
> Markus Wanner <[hidden email]> writes:
>> 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 landed this on nvm .. uhm .. several moons ago.

> So as long as you don't change 'mtn auto inventory', this does not
> affect me.

No changes (intended) for auto inventory.

> One goal might be to make it closer to 'git status', and or 'hg status',
> so people migrating to/from those are comfortable.

I know git a bit, but didn't really try to mimic it. I don't use mercurial.

>> 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.
>
> +1
>
> This happens on 'mtn update' as well;

Yes. Unlike status, update is a potentially destructive command. IMO the
best we can do in that case in listing *all* causes that prevent an
update (rather than just the first error).

> that annoys me, since 'update' is
> very similar to 'revert'! Perhaps we need an 'update --revert', meaning
> "revert as needed, then update".

I don't see much benefit over just 'revert then update'. I certainly
wouldn't remember the special argument. :-)

Regards

Markus Wanner


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