{"thread":{"id":"15450","subject":"Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","startedAt":"2008-09-09T13:26:43Z","lastAt":"2008-09-09T23:02:46Z","messageCount":13,"participants":["Elijah Newren","Jakub Narebski","Govind Salinas","Steven Walter","Petr Baudis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90213","messageId":"51419b2c0809090626p2196c590j7569fb471e470f0d@mail.gmail.com","threadId":"15450","inReplyTo":null,"subject":"Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-09T13:26:43Z","receivedAt":"2008-09-09T13:26:43Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas\n wrote:\n> On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter wrote:\n\n> I had some very different ideas along the lines of reducing the number of\n> commands (where the commands do something similar just DWIM rather\n> than force me to remember or read docs on different commands), making\n> commands look similar to commands from other SCMs (revert should do\n> what it does for me in all the other SCMs that I have used, which is to\n> checkout the HEAD copy into the working directory)\n\nYour description of revert in various systems isn't quite accurate; it\nisn't necessarily HEAD, since most systems (at least bzr and hg) can\nalso revert files to revisions earlier than HEAD. In fact, questions\nof how to do that have come up several times on this list, so you\nwouldn't want to exclude that case. Also, the revert behavior of git\n(minus perhaps the default auto-commit) comes in pretty handy too\nsometimes, and I can't easily find it in other systems (I suspect many\njust drop back to diff + patch to handle the case that git provides).\n\nI don't see why the revert command can't support all these cases that\nusers want (though you'd need to add flags like --since and --in to\ndifferentiate between reverting the changes since a given commit or in\na given commit). Doing so has the added advantage that you can\navoid/deprecate/hide/whatever the second forms of the checkout and\nreset commands of git, which have long caused confusion for users in\nunderstanding the differences between them and the revert command.\n\nElijah\n\nP.S. Yes, EasyGit's revert was designed this way. Don't look to eg\nfor implementation guidance, though -- I botched it, and there's a few\nbugs in it due to my mistakes. I'll be fixing it...when I get a\nlittle bit of time.\n"},{"id":"90215","messageId":"200809091538.13961.jnareb@gmail.com","threadId":"15450","inReplyTo":"51419b2c0809090626p2196c590j7569fb471e470f0d@mail.gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-09T13:38:13Z","receivedAt":"2008-09-09T13:38:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Elijah Newren wrote:\n> On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas\n> wrote:\n> > On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter wrote:\n> \n> > I had some very different ideas along the lines of reducing the number of\n> > commands (where the commands do something similar just DWIM rather\n> > than force me to remember or read docs on different commands), making\n> > commands look similar to commands from other SCMs (revert should do\n> > what it does for me in all the other SCMs that I have used, which is to\n> > checkout the HEAD copy into the working directory)\n> \n> Your description of revert in various systems isn't quite accurate; it\n> isn't necessarily HEAD, since most systems (at least bzr and hg) can\n> also revert files to revisions earlier than HEAD. In fact, questions\n> of how to do that have come up several times on this list, so you\n> wouldn't want to exclude that case. Also, the revert behavior of git\n> (minus perhaps the default auto-commit) comes in pretty handy too\n> sometimes, and I can't easily find it in other systems (I suspect many\n> just drop back to diff + patch to handle the case that git provides).\n[...]\n\nBy the way, I think the fact that in different SCMs meaning of\n\"$scm revert\" and of \"$scm reset\" differs widely caused Mercurial\nto adopt \"hg backout\" for creating a commit which reverts changes\n(cherry-pick -R), and \"hg rollback\" to undo last commit.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"90235","messageId":"5d46db230809090937k44fc569ct7eda35b9ee86cb22@mail.gmail.com","threadId":"15450","inReplyTo":"200809091538.13961.jnareb@gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Govind Salinas","fromEmail":"govind@sophiasuchtig.com","sentAt":"2008-09-09T16:37:40Z","receivedAt":"2008-09-09T16:37:40Z","isPatch":false,"sender":{"key":"govind@sophiasuchtig.com","avatar":null},"body":"On Tue, Sep 9, 2008 at 8:38 AM, Jakub Narebski wrote:\n> Elijah Newren wrote:\n>> On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas\n>> wrote:\n>> > On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter wrote:\n>>\n>> > I had some very different ideas along the lines of reducing the number of\n>> > commands (where the commands do something similar just DWIM rather\n>> > than force me to remember or read docs on different commands), making\n>> > commands look similar to commands from other SCMs (revert should do\n>> > what it does for me in all the other SCMs that I have used, which is to\n>> > checkout the HEAD copy into the working directory)\n>>\n>> Your description of revert in various systems isn't quite accurate; it\n>> isn't necessarily HEAD, since most systems (at least bzr and hg) can\n>> also revert files to revisions earlier than HEAD. In fact, questions\n>> of how to do that have come up several times on this list, so you\n>> wouldn't want to exclude that case. Also, the revert behavior of git\n>> (minus perhaps the default auto-commit) comes in pretty handy too\n>> sometimes, and I can't easily find it in other systems (I suspect many\n>> just drop back to diff + patch to handle the case that git provides).\n> [...]\n>\n> By the way, I think the fact that in different SCMs meaning of\n> \"$scm revert\" and of \"$scm reset\" differs widely caused Mercurial\n> to adopt \"hg backout\" for creating a commit which reverts changes\n> (cherry-pick -R), and \"hg rollback\" to undo last commit.\n>\n\nMy take on this comes from my own personal experience with \"revert\"\ncommands, the fact that \"how do i undo my working dir changes\" is\nthe most common question I see on the list and that I have heard\nothers with the same complaint.\n\nI will concede that revert usually means both \"discard current working\ndir changes\" and \"undo a previous change\" in different circumstances.\nHowever, the number of times that \"how do i discard my working\ndir changes\" comes up on the list leads me to believe that you get\nthe most out of using revert for this, since it is something that should\nbe familiar to a user and undoing a previous commit is more rare.\n\nOf course, this is where I would use a DWIM-ism.\n\"pyt revert -r commitish\" would generate a reverse patch but\n\"pyt revert ...\" would checkout from HEAD. \"pyt revert\" would\njust \"git reset --hard\".\n\n-Govind\n"},{"id":"90238","messageId":"e06498070809091029j1e450c43i276c5a69376da3ab@mail.gmail.com","threadId":"15450","inReplyTo":"5d46db230809090937k44fc569ct7eda35b9ee86cb22@mail.gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-09T17:29:10Z","receivedAt":"2008-09-09T17:29:10Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Sep 9, 2008 at 12:37 PM, Govind Salinas\n wrote:\n> My take on this comes from my own personal experience with \"revert\"\n> commands, the fact that \"how do i undo my working dir changes\" is\n> the most common question I see on the list and that I have heard\n> others with the same complaint.\n>\n> I will concede that revert usually means both \"discard current working\n> dir changes\" and \"undo a previous change\" in different circumstances.\n> However, the number of times that \"how do i discard my working\n> dir changes\" comes up on the list leads me to believe that you get\n> the most out of using revert for this, since it is something that should\n> be familiar to a user and undoing a previous commit is more rare.\n>\n> Of course, this is where I would use a DWIM-ism.\n> \"pyt revert -r commitish\" would generate a reverse patch but\n> \"pyt revert ...\" would checkout from HEAD. \"pyt revert\" would\n> just \"git reset --hard\".\n\nIn yap, \"revert\" is used to discard working copy changes. \"revert -a\"\nreverts all changes; just \"revert\" replies \"nothing to do.\" Having\n\"pyt revert\" = \"git reset --hard\" makes me queasy; especially in\nDvorak it's all too easy to hit Enter when reaching for '/'; seems\nlike a catastrophe waiting to happen.\n\nI tend to dislike \"DWIM\" in interfaces, because the computer cannot\nread your mind, and can therefore never know with certainty what I\nmean. Especially in cases where the computer thinks I intend to\nperform an irreversible operation, I want the computer to ask first.\nNot only that, but I think having one command that does 10 different\nthings is as confusing as 10 commands that each do one thing. My\nphilosophy has been to identify frequent operations and give them\nsensible commands, rather than overloading a handful of operations or\nrequiring multiple commands for common tasks. My philosophy has also\nbeen not to wrap every command. If a user were to ask me, \"I want to\nbisect a changeset,\" my response would be \"okay, use git bisect.\" If\nthe user wants such a specialized command as that, then they shouldn't\nhave trouble with dealing directly with git for that operation.\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90254","messageId":"51419b2c0809091319j2f29b6e1n752cba305c7c1cf6@mail.gmail.com","threadId":"15450","inReplyTo":"e06498070809091029j1e450c43i276c5a69376da3ab@mail.gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-09T20:19:15Z","receivedAt":"2008-09-09T20:19:15Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Sep 9, 2008 at 11:29 AM, Steven Walter wrote:\n>> Of course, this is where I would use a DWIM-ism.\n>> \"pyt revert -r commitish\" would generate a reverse patch but\n>> \"pyt revert ...\" would checkout from HEAD. \"pyt revert\" would\n>> just \"git reset --hard\".\n>\n> In yap, \"revert\" is used to discard working copy changes. \"revert -a\"\n> reverts all changes; just \"revert\" replies \"nothing to do.\" Having\n> \"pyt revert\" = \"git reset --hard\" makes me queasy; especially in\n> Dvorak it's all too easy to hit Enter when reaching for '/'; seems\n> like a catastrophe waiting to happen.\n\nI agree with that, and a plain \"eg revert\" does nothing other than\nprovide a suggestion for the user as well.\n\n> I tend to dislike \"DWIM\" in interfaces, because the computer cannot\n> read your mind, and can therefore never know with certainty what I\n> mean. Especially in cases where the computer thinks I intend to\n> perform an irreversible operation, I want the computer to ask first.\n> Not only that, but I think having one command that does 10 different\n> things is as confusing as 10 commands that each do one thing. My\n\nHow are these things really different, though? People occasionally\nwant to \"revert changes\". Now, this may be the changes between 32 and\n29 revisions ago, it might be all changes since the last commit, it\ncould be the changes since 3 commits ago, or it could be just one\nspecific commit. The user may want to subset such reversions to just\nspecific files, but it all boils down to \"reverting changes\" in the\nend. Now, eg can't yet handle a range like between 32 and 29\nrevisions ago (because I wasn't sure what syntax I'd want to use for\nit), but it's fairly straightforward to say any of:\n\n eg revert --since HEAD~3 # Undo all changes since HEAD~3\n eg revert --in HEAD~8 # much like git revert HEAD~8, but no\ncommit by default\n eg revert --since HEAD foo.py # Undo changes to foo.py since last commit\n eg revert foo.py # Same as above\n eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]\n\nWhat doesn't work is\n\n eg revert trial~7\n\nsince I don't know whether the user wants to revert changes in that\ncommit, or since that commit (so this is a minor backward\ncompatibility break I made with core git). But eg provides a simple\nwarning with suggestions, which teaches the user the correct command\nas well as potentially showing them some new functionality.\n\nAre these kinds of \"reverting data\" really so different that there\nshould need to be different commands, or that some of these operations\nshouldn't be supported by the simple revert command? Sure, most users\nmost of the time will probably use the \"eg revert FILE1 FILE2...\"\nform, but I didn't see the harm in supporting the extra capabilities.\n\nAlso...is there anything fundamental that would keep core git from\nadopting such behavior? It'd solve lots of user questions[1], but\nwould also have some potential backward compatibility issues for\nscripts[2] (which may be reason enough to not adopt it, I know).\n\n\nElijah\n\n[1] For example, \"how do I revert all changes since commit x?\", \"how\ndo I revert the recent modification to a certain file?\", and \"what's\nthe difference between checkout, reset, and revert?\"\n\n[2] commits by default don't make sense for the generalized revert\ncommand, and \"git revert REVISION\" would error out with instructions\n(telling the user to add the --in flag).\n"},{"id":"90255","messageId":"51419b2c0809091320jaf66a20y46b78972130af58d@mail.gmail.com","threadId":"15450","inReplyTo":"200809091538.13961.jnareb@gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-09T20:20:59Z","receivedAt":"2008-09-09T20:20:59Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Sep 9, 2008 at 7:38 AM, Jakub Narebski wrote:\n> By the way, I think the fact that in different SCMs meaning of\n> \"$scm revert\" and of \"$scm reset\" differs widely caused Mercurial\n> to adopt \"hg backout\" for creating a commit which reverts changes\n> (cherry-pick -R), and \"hg rollback\" to undo last commit.\n\nAh, I had somehow missed hg backout. Thanks for the pointer!\n\nElijah\n"},{"id":"90272","messageId":"20080909212834.GC10544@machine.or.cz","threadId":"15450","inReplyTo":"200809091538.13961.jnareb@gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-09T21:28:34Z","receivedAt":"2008-09-09T21:28:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Sep 09, 2008 at 03:38:13PM +0200, Jakub Narebski wrote:\n> By the way, I think the fact that in different SCMs meaning of\n> \"$scm revert\" and of \"$scm reset\" differs widely caused Mercurial\n> to adopt \"hg backout\" for creating a commit which reverts changes\n> (cherry-pick -R), and \"hg rollback\" to undo last commit.\n\nThis brings up a point I wanted to raise - sometimes when the meanings\nacross the systems (including Git) are too conflicting, it should be\nconsidered to use a completely different command name whatsoever to\nreduce the confusion. This is e.g. the reason Cogito had no \"pull\"\n(but \"update\") or \"checkout\" (but \"restore\" and \"switch\") commands.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"90275","messageId":"e06498070809091439q1c543807pd6e74b7ada32434@mail.gmail.com","threadId":"15450","inReplyTo":"20080909212834.GC10544@machine.or.cz","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-09T21:39:46Z","receivedAt":"2008-09-09T21:39:46Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Sep 9, 2008 at 5:28 PM, Petr Baudis wrote:\n> On Tue, Sep 09, 2008 at 03:38:13PM +0200, Jakub Narebski wrote:\n>> By the way, I think the fact that in different SCMs meaning of\n>> \"$scm revert\" and of \"$scm reset\" differs widely caused Mercurial\n>> to adopt \"hg backout\" for creating a commit which reverts changes\n>> (cherry-pick -R), and \"hg rollback\" to undo last commit.\n>\n> This brings up a point I wanted to raise - sometimes when the meanings\n> across the systems (including Git) are too conflicting, it should be\n> considered to use a completely different command name whatsoever to\n> reduce the confusion. This is e.g. the reason Cogito had no \"pull\"\n> (but \"update\") or \"checkout\" (but \"restore\" and \"switch\") commands.\n\nI agree with this. That's part of the problem I have with schemes to\nmake commands work similarly to other SCMs. If you give, for example,\neg a mode to act like \"svn revert;\" that all well and good until the\nuser runs \"git diff\" and you're made a liar. In svn, there would be\nno diff, because the files all match their respective upstream\nversions. In git, you would see changes because the file no longer\nmatches the last commit.\n\nIt it a delicate balance to have the user interface match both the\nmental model of the user and the storage model of the tool. That's\nwhat all of these projects, (git, cogito, yap, eg, pyrite) are\nattempting to do. I don't know of an objective way to measure success\nin this attempt, other than simple popularity. Popularity suggests\nthat the git porcelain is the most successful, and I would agree\nregarding storage model, but I am not convinced that it best matches a\ntypical SCM user's mental model.\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90276","messageId":"e06498070809091450y3bb7ba1cs8b86ea31b4e37bd8@mail.gmail.com","threadId":"15450","inReplyTo":"51419b2c0809091319j2f29b6e1n752cba305c7c1cf6@mail.gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-09T21:50:47Z","receivedAt":"2008-09-09T21:50:47Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren wrote:\n>> I tend to dislike \"DWIM\" in interfaces, because the computer cannot\n>> read your mind, and can therefore never know with certainty what I\n>> mean. Especially in cases where the computer thinks I intend to\n>> perform an irreversible operation, I want the computer to ask first.\n>> Not only that, but I think having one command that does 10 different\n>> things is as confusing as 10 commands that each do one thing. My\n>\n> How are these things really different, though? People occasionally\n> want to \"revert changes\". Now, this may be the changes between 32 and\n> 29 revisions ago, it might be all changes since the last commit, it\n> could be the changes since 3 commits ago, or it could be just one\n> specific commit. The user may want to subset such reversions to just\n> specific files, but it all boils down to \"reverting changes\" in the\n> end. Now, eg can't yet handle a range like between 32 and 29\n> revisions ago (because I wasn't sure what syntax I'd want to use for\n> it), but it's fairly straightforward to say any of:\n>\n> eg revert --since HEAD~3 # Undo all changes since HEAD~3\n> eg revert --in HEAD~8 # much like git revert HEAD~8, but no\n> commit by default\n> eg revert --since HEAD foo.py # Undo changes to foo.py since last commit\n> eg revert foo.py # Same as above\n> eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]\n[...]\n> Are these kinds of \"reverting data\" really so different that there\n> should need to be different commands, or that some of these operations\n> shouldn't be supported by the simple revert command? Sure, most users\n> most of the time will probably use the \"eg revert FILE1 FILE2...\"\n> form, but I didn't see the harm in supporting the extra capabilities.\n\nThe harm I see in trying to support every possible use case is that it\nmakes it exponentially more difficult to fully understand the tool.\nUsing yap as an example, I think it should be easy enough for a user\nto read the help blurb for every command and understand what it does\nand when to use it (this is easy for me to say as the author, but I\nthink it would hold true for a \"typical SCM user.\") Having a mode\nthe seems to act like another SCM (revert --since) seems great at\nfirst blush. The user will see that and think, \"Wonderful, this will\nwork just like svn and I don't have to think about it.\" As I mention\nin another email, that's all well and good until the user runs \"git\ndiff\" and makes a liar of you. In svn, there would be no diff,\nbecause the files all match their respective upstream versions. In\ngit, you would see changes because the file no longer matches the last\ncommit. Now your user is confused because his mental model was\nviolated.\n\nObviously, there is a trade-off here between power and usability. As\nshown by the Hole Hawg[1], there is a limit to the amount of power it\nis useful for the average user to have. The git community has already\nadmitted this by dividing the git command set into two classes:\nplumbing, and porcelain. \"The plumbing,\" you say, \"is very powerful,\nbut you shouldn't have to use it.\" My contention is that there is a\nclass of users that is not well served by the current definition of\nporcelain. It is that class of users that I have tried to target with\nyap.\n\n[1] http://www.cryptonomicon.com/beginning.html\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90279","messageId":"7v63p53r93.fsf@gitster.siamese.dyndns.org","threadId":"15450","inReplyTo":"e06498070809091439q1c543807pd6e74b7ada32434@mail.gmail.com","subject":"Re: Revert behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T22:10:16Z","receivedAt":"2008-09-09T22:10:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Steven Walter\" writes:\n\n> I agree with this. That's part of the problem I have with schemes to\n> make commands work similarly to other SCMs. If you give, for example,\n> eg a mode to act like \"svn revert;\" that all well and good until the\n> user runs \"git diff\" and you're made a liar. In svn, there would be\n> no diff, because the files all match their respective upstream\n> versions. In git, you would see changes because the file no longer\n> matches the last commit.\n\nIf you implement \"eg svn-like-revert\" to checkout the given paths out of\nthe last commit, instead of the index, shouldn't that be sufficient?\n\n> It it a delicate balance to have the user interface match both the\n> mental model of the user and the storage model of the tool.\n\nI do not think it is that simple.\n\nYou could match the user experience to the mental model of the other tool,\nby hiding the differences and insisting that people use only your tool.\n\nThe real issue is that you may need to castrate the underlying tool in\ncertain places if its world model is richer than the model the tool you\nare trying to emulate. Ignoring the index by making \"svn-like-revert\"\nwork on both index and the working tree file at the same time is a good\nexample of that.\n\nIf the castrated feature is truly too exotic and rarely useful for mere\nmortals, that strategy works very well. A simpler world model that lets\nyou do the same job equally well is a much better UI than the needlessly\ncomplex one. But if that is not the case, your users would eventually\ngraduate out of the training wheel and would want to use that feature you\nhid away from them, and at that point they need to unlearn parts of the\nsimpler world model and shift their world view somewhat. If you try to\nsupport both classes of users, that become hard.\n\nI have to admit that I used to have my own Porcelain when git was very\nyoung, not because I did not like existing UI git had, but there was no UI\nback then. \"My own\" Porcelain is relatively easy -- I have to only cater\nto my own needs and need to expose only the limited subset of the features\nthe underlying tool (in this case, the storage model and history view of\ngit) I understand, and nobody complains that he cannot access the parts I\ndo not expose to him. Growing it to satisfy wider audience is the hard\npart.\n"},{"id":"90281","messageId":"e06498070809091530n57913304r2eb3920898a3225d@mail.gmail.com","threadId":"15450","inReplyTo":"7v63p53r93.fsf@gitster.siamese.dyndns.org","subject":"Re: Revert behavior","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-09T22:30:05Z","receivedAt":"2008-09-09T22:30:05Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Sep 9, 2008 at 6:10 PM, Junio C Hamano wrote:\n> If you implement \"eg svn-like-revert\" to checkout the given paths out of\n> the last commit, instead of the index, shouldn't that be sufficient?\n\neg's \"revert --since \" command is actually most similar\nto \"svn update -rXXX path.\" In this case, except for the special case\nwhere commit is HEAD, it is not sufficient; checking the path out of\nthe last commit would not be what the user wanted.\n\n>> It it a delicate balance to have the user interface match both the\n>> mental model of the user and the storage model of the tool.\n>\n> I do not think it is that simple.\n>\n> You could match the user experience to the mental model of the other tool,\n> by hiding the differences and insisting that people use only your tool.\n>\n> The real issue is that you may need to castrate the underlying tool in\n> certain places if its world model is richer than the model the tool you\n> are trying to emulate. Ignoring the index by making \"svn-like-revert\"\n> work on both index and the working tree file at the same time is a good\n> example of that.\n>\n> If the castrated feature is truly too exotic and rarely useful for mere\n> mortals, that strategy works very well. A simpler world model that lets\n> you do the same job equally well is a much better UI than the needlessly\n> complex one. But if that is not the case, your users would eventually\n> graduate out of the training wheel and would want to use that feature you\n> hid away from them, and at that point they need to unlearn parts of the\n> simpler world model and shift their world view somewhat. If you try to\n> support both classes of users, that become hard.\n\nIndeed so. Hiding the index is not a design goal of yap. However,\nneither is it absolutely necessary to understand the distinction\nbetween \"staged\" and \"unstaged\" changes to use yap. If a use never\nruns the \"stage\" command, everything would work as he expects.\nAchieving this is as simple as making \"yap commit,\" in the presence of\nonly unstaged changes, do the equivalent of \"git commit -a.\" If it\nturns out that _wasn't_ what the user wanted, salvation is only a \"yap\nuncommit\" away.\n\nIn your position as an integrator, what is a necessary tool for you\nmay indeed be an exotic command for another user. For example, users\nwho primarily interact with svn repositories (a target demographic for\nyap), \"merge\" is not terribly useful given the information loss when a\ncommit is eventually \"pushed\" to subversion. I do not hide merge\nfunctionality, but neither is it emphasized as a standard part of the\nworkflow (there is no \"pull\" command).\n\n> I have to admit that I used to have my own Porcelain when git was very\n> young, not because I did not like existing UI git had, but there was no UI\n> back then. \"My own\" Porcelain is relatively easy -- I have to only cater\n> to my own needs and need to expose only the limited subset of the features\n> the underlying tool (in this case, the storage model and history view of\n> git) I understand, and nobody complains that he cannot access the parts I\n> do not expose to him. Growing it to satisfy wider audience is the hard\n> part.\n\nNo argument that supporting an audience greater than 1 is considerably\nmore difficult. Indeed I intend and hope to support users other than\nmyself with yap, else I would not have gone to the trouble of\nannouncing it. However, without concrete discussion on where yap\nhides too much or \"castrates\" a feature in a way that hinders learning\nof the lower-level tools, there's only so much one can do.\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90283","messageId":"51419b2c0809091551n6f1f627cica23312795502225@mail.gmail.com","threadId":"15450","inReplyTo":"7v63p53r93.fsf@gitster.siamese.dyndns.org","subject":"Re: Revert behavior","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-09T22:51:20Z","receivedAt":"2008-09-09T22:51:20Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Sep 9, 2008 at 4:10 PM, Junio C Hamano wrote:\n> If you implement \"eg svn-like-revert\" to checkout the given paths out of\n> the last commit, instead of the index, shouldn't that be sufficient?\n\nNo, that would leave staged changes unreverted -- a particular case of\nwhich means that revert wouldn't be able to undo an add operation.\nFor svn-like-revert, the default should be for both staged and\nunstaged changes to be undone, unless the user specifically requested\nthat only part of the changes be reverted (e.g. with --staged or\n--unstaged flags). Making revert work prior to the initial commit for\nnew adds is another case that needs a command with behavior different\nthan git's checkout of paths.\n\n>> It it a delicate balance to have the user interface match both the\n>> mental model of the user and the storage model of the tool.\n>\n> I do not think it is that simple.\n>\n> You could match the user experience to the mental model of the other tool,\n> by hiding the differences and insisting that people use only your tool.\n>\n> The real issue is that you may need to castrate the underlying tool in\n> certain places if its world model is richer than the model the tool you\n> are trying to emulate. Ignoring the index by making \"svn-like-revert\"\n> work on both index and the working tree file at the same time is a good\n> example of that.\n\nWhy? If the command _by default_ works on both the index and working\ntree file, is that necessarily bad ('git checkout BRANCH' operates on\nboth)? If the tool can only operate on both at once, then sure, I\nagree, but that at least isn't the case with eg and wasn't my\nsuggestion for git.\n\nNot all alternate porcelains try to hide or destroy the index. Some\nof us really do love it.\n\n\nElijah\n"},{"id":"90285","messageId":"51419b2c0809091602g35b9aa2g8202c46a4f603cdd@mail.gmail.com","threadId":"15450","inReplyTo":"e06498070809091450y3bb7ba1cs8b86ea31b4e37bd8@mail.gmail.com","subject":"Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-09-09T23:02:46Z","receivedAt":"2008-09-09T23:02:46Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Sep 9, 2008 at 3:50 PM, Steven Walter wrote:\n> On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren wrote:\n>> it), but it's fairly straightforward to say any of:\n>>\n>> eg revert --since HEAD~3 # Undo all changes since HEAD~3\n>> eg revert --in HEAD~8 # much like git revert HEAD~8, but no\n>> commit by default\n>> eg revert --since HEAD foo.py # Undo changes to foo.py since last commit\n>> eg revert foo.py # Same as above\n>> eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]\n> [...]\n>> Are these kinds of \"reverting data\" really so different that there\n>> should need to be different commands, or that some of these operations\n>> shouldn't be supported by the simple revert command? Sure, most users\n>> most of the time will probably use the \"eg revert FILE1 FILE2...\"\n>> form, but I didn't see the harm in supporting the extra capabilities.\n>\n> The harm I see in trying to support every possible use case is that it\n> makes it exponentially more difficult to fully understand the tool.\n> Using yap as an example, I think it should be easy enough for a user\n> to read the help blurb for every command and understand what it does\n> and when to use it (this is easy for me to say as the author, but I\n> think it would hold true for a \"typical SCM user.\") Having a mode\n> the seems to act like another SCM (revert --since) seems great at\n> first blush. The user will see that and think, \"Wonderful, this will\n> work just like svn and I don't have to think about it.\" As I mention\n> in another email, that's all well and good until the user runs \"git\n> diff\" and makes a liar of you. In svn, there would be no diff,\n> because the files all match their respective upstream versions. In\n> git, you would see changes because the file no longer matches the last\n> commit. Now your user is confused because his mental model was\n> violated.\n\nUm, no, git diff won't make a liar of me -- it'll come up empty as\nexpected. :-) My suggestion for revert does make it a logical\nextension of svn's, and includes git revert's behavior (with two minor\ntweaks). See my follow up post to Junio's elsewhere in this thread.\n\n> Obviously, there is a trade-off here between power and usability. As\n> shown by the Hole Hawg[1], there is a limit to the amount of power it\n> is useful for the average user to have. The git community has already\n> admitted this by dividing the git command set into two classes:\n> plumbing, and porcelain. \"The plumbing,\" you say, \"is very powerful,\n> but you shouldn't have to use it.\" My contention is that there is a\n> class of users that is not well served by the current definition of\n> porcelain. It is that class of users that I have tried to target with\n> yap.\n\nFair enough. I too had to make decisions on what to focus on as well\nin Easy Git. Since my goal was more along the lines of \"make it easy\nto learn how to use git, and particularly easy to transition to and\nfrom git and eg\" that gives me a much different frame of reference\nthan interoperating with svn (which I essentially ignored). I thought\nthat this particular case didn't add much complexity (and potentially\neven removed it elsewhere), but that may just be my frame of\nreference.\n\nyap looks pretty cool; I'll have to take a look sometime.\n"}]}