{"thread":{"id":"12957","subject":"\"stg reset --status\" doesn't just reset status","startedAt":"2008-04-02T02:21:24Z","lastAt":"2008-04-02T17:30:24Z","messageCount":3,"participants":["Pavel Roskin","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73527","messageId":"20080401222124.1b4niqtm0ogw40sk@webmail.spamcop.net","threadId":"12957","inReplyTo":null,"subject":"\"stg reset --status\" doesn't just reset status","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2008-04-02T02:21:24Z","receivedAt":"2008-04-02T02:21:24Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI used to see messages like this:\n\n$ stg pull\nChecking for changes in the working directory ... done\nstg pull: local changes in the tree. Use \"refresh\" or \"status --reset\"\n\nThis time I decided to see what \"stg reset --status\" actually does,  \nand I was unpleasantly surprised that it would do much more that its  \nname implies.\n\nIt doesn't just reset the status (no idea what it would be, but it  \ndoesn't sound scary).  It removes all local changes.  It's essentially  \n\"git reset --hard\".  I can easily imagine that some beginner would  \nlose valuable changes by following that advice while trying to update  \nfrom the upstream repository.\n\nI would hate to suggest another stg command, as there are too many of  \nthem already.  On the other hand, if \"applied\" and \"unapplied\" are  \ndowngraded to switches for \"stg series\", we probably could justify  \nadding one more command, \"stg reset\".  By the way, the default could  \nbe to save the changes to a hidden \"stash\" patch, and the \"--hard\"  \nswitch would do a real reset.\n\nAnother (not alternative) approach would be to have an option to \"stg  \npull\" to save the changes as a temporary patch that would be applied  \nand deleted if it applied cleanly.  That shouldn't be a default for  \n\"stg pull\", as it's likely that the user just forgot \"stg refresh\".\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"73542","messageId":"20080402120026.GA17241@diana.vm.bytemark.co.uk","threadId":"12957","inReplyTo":"20080401222124.1b4niqtm0ogw40sk@webmail.spamcop.net","subject":"Re: \"stg reset --status\" doesn't just reset status","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-04-02T12:00:26Z","receivedAt":"2008-04-02T12:00:26Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-04-01 22:21:24 -0400, Pavel Roskin wrote:\n\n> This time I decided to see what \"stg reset --status\" actually does,\n> and I was unpleasantly surprised that it would do much more that its\n> name implies.\n>\n> It doesn't just reset the status (no idea what it would be, but it\n> doesn't sound scary). It removes all local changes. It's essentially\n> \"git reset --hard\". I can easily imagine that some beginner would\n> lose valuable changes by following that advice while trying to\n> update from the upstream repository.\n>\n> I would hate to suggest another stg command, as there are too many\n> of them already. On the other hand, if \"applied\" and \"unapplied\" are\n> downgraded to switches for \"stg series\", we probably could justify\n> adding one more command, \"stg reset\". By the way, the default could\n> be to save the changes to a hidden \"stash\" patch, and the \"--hard\"\n> switch would do a real reset.\n\n(I assume \"stg reset --status\" is just a typo for \"stg status\n--reset\"?)\n\nI'd be fine with removing status --reset, but since there is currently\nno other way to do this in StGit, I expect Catalin would object. (As I\nrecall, that's precisely what happened when I did try to remove it\nsome time ago.)\n\nI'm currently (slowly) working on an \"stg reset\" command that'll be\nable to reset the stack to any prior state. It could be made to reset\nto the most recent recorded state if no extra argument is given, which\nI think would make it do what you want.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"73552","messageId":"1207157424.5828.16.camel@dv","threadId":"12957","inReplyTo":"20080402120026.GA17241@diana.vm.bytemark.co.uk","subject":"Re: \"stg reset --status\" doesn't just reset status","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2008-04-02T17:30:24Z","receivedAt":"2008-04-02T17:30:24Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Wed, 2008-04-02 at 14:00 +0200, Karl Hasselström wrote:\n\n> (I assume \"stg reset --status\" is just a typo for \"stg status\n> --reset\"?)\n\nExactly.  \"stg status --reset\" is so against the logic that I could not\neven write it properly :)\n\n> I'd be fine with removing status --reset, but since there is currently\n> no other way to do this in StGit, I expect Catalin would object. (As I\n> recall, that's precisely what happened when I did try to remove it\n> some time ago.)\n\n1) stg diff | patch -Rp1\n2) stg new -m \"trash\" trash; stg refresh; stg delete trash\n\nBesides, I don't think everything should be easily doable from stgit.\n\n> I'm currently (slowly) working on an \"stg reset\" command that'll be\n> able to reset the stack to any prior state. It could be made to reset\n> to the most recent recorded state if no extra argument is given, which\n> I think would make it do what you want.\n\nSounds good.  Thank you!\n\n-- \nRegards,\nPavel Roskin\n"}]}