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' 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 |
On 12/10/14 15:10, Markus Wanner wrote:
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.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 Tony. _______________________________________________ Monotone-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/monotone-devel |
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 |
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 |
Free forum by Nabble | Edit this page |