{"thread":{"id":"29005","subject":"Proposal: create meaningful aliases for git reset's hard/soft/mixed","startedAt":"2011-11-23T08:28:19Z","lastAt":"2012-12-18T16:30:57Z","messageCount":22,"participants":["Philippe Vaucher","Matthieu Moy","Nguyen Thai Ngoc Duy","Junio C Hamano","Phil Hord","Thomas Rast","Miles Bader","Jan Engelhardt","Martin von Zweigbergk","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179863","messageId":"CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com","threadId":"29005","inReplyTo":null,"subject":"Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-11-23T08:28:19Z","receivedAt":"2011-11-23T08:28:19Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"Hello,\n\nA lot of time when I want to use reset for smth else than \"--hard\" I\nhave to go and look the documentation.\nI think the modes could be improved by creating new aliases like this:\n\nOptional: a new mode would be introduced for consistency:\n--worktree (or maybe --tree): only updates the worktree but not the index\n\nThen the existing mode could be aliased like this:\n--mixed would be aliased as --index\n--hard would be aliased as --all\n--soft could be aliased as --no-changes\n\nAdditionally:\n--merge could be removed in favor of an additional --preserve-staged flag\n--keep could be removed in favor of an additional --safe flag\n\nSo if I recap my ideas:\n\n\"I want to discard my changes\" --> git reset --all HEAD^\n\"I want to discard the last commit\" --> git reset --index HEAD^\n\"I want to discard the last commit, but let's be safe in case I forgot\nabout a modified file\" --> git reset --all --safe HEAD^\n\"I want to discard the last commit, keep my current staged changes\"\n--> git reset --all --preserve-staged HEAD^\n\nPhilippe\n"},{"id":"179865","messageId":"vpq4nxvusty.fsf@bauges.imag.fr","threadId":"29005","inReplyTo":"CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-11-23T08:49:13Z","receivedAt":"2011-11-23T08:49:13Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Philippe Vaucher writes:\n\n> A lot of time when I want to use reset for smth else than \"--hard\" I\n> have to go and look the documentation.\n\nI have to agree with this, I took a lot of time to understand/memorize\nthe meaning of reset options.\n\n> Optional: a new mode would be introduced for consistency:\n> --worktree (or maybe --tree): only updates the worktree but not the index\n\nThat would be an alias for \"git checkout -- path\", right?\n\nI don't really like this \"there is more than one way to do it\" in Git's\ncommand-line, I think we should think very carefully before introducing\nyet another instance of it.\n\n> --keep could be removed in favor of an additional --safe flag\n\nIf you are to change the option names, then you should also make the\nbehavior safe by default:\n\n* \"git reset --all\" = \"git reset --keep\"\n* \"git reset --all --force\" = \"git reset --hard\"\n\nWith the current terminology, --hard has the advantage that it makes it\nrealatively clear how dangerous it is. Still, I've seen users losing\ndata because they did a \"git reset --hard\" with uncommited changes. Git\nis safe by default most of the time, and \"git reset --hard\" is one\nunfortunate exception (because it was there before --keep, people are\nmore used to it).\n\n\"git reset --all\" would make it worse, because the option name is less\nscary, people would be less reluctant to use it, and would get more\nchance to lose data.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"179877","messageId":"CAGK7Mr7+5x2+=7H=UQhVw56coBO7J4Ot8weckAg=V2TujLM9BQ@mail.gmail.com","threadId":"29005","inReplyTo":"vpq4nxvusty.fsf@bauges.imag.fr","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-11-23T11:32:17Z","receivedAt":"2011-11-23T11:32:17Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> Optional: a new mode would be introduced for consistency:\n>> --worktree (or maybe --tree): only updates the worktree but not the index\n>\n> That would be an alias for \"git checkout -- path\", right?\n\nHum... yeah probably, what motivated me was that there's a way to\nreset the index and not the worktree, but there's no way to reset the\nworktree but not the index. I guess it's \"checkout\" as you pointed\nout.\n\n\n>> --keep could be removed in favor of an additional --safe flag\n>\n> If you are to change the option names, then you should also make the\n> behavior safe by default:\n>\n> * \"git reset --all\" = \"git reset --keep\"\n> * \"git reset --all --force\" = \"git reset --hard\"\n\nYes that's actually much better. Let's change my proposal to that.\n\nPhilippe\n"},{"id":"179880","messageId":"CACsJy8CuEaH33B_wrLo0BXYaYWi5tHB3tncftHhBQgiv9QcgaA@mail.gmail.com","threadId":"29005","inReplyTo":"CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-11-23T12:02:35Z","receivedAt":"2011-11-23T12:02:35Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Nov 23, 2011 at 3:28 PM, Philippe Vaucher\n wrote:\n> Hello,\n>\n> A lot of time when I want to use reset for smth else than \"--hard\" I\n> have to go and look the documentation.\n\nMay be related: http://thread.gmane.org/gmane.comp.version-control.git/170266\n-- \nDuy\n"},{"id":"179900","messageId":"7vlir6brjw.fsf@alter.siamese.dyndns.org","threadId":"29005","inReplyTo":"CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-23T18:51:47Z","receivedAt":"2011-11-23T18:51:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Vaucher writes:\n\n> So if I recap my ideas:\n>\n> \"I want to discard my changes\" --> git reset --all HEAD^\n\nThat is discarding your changes and also the last commit.\n\n> \"I want to discard the last commit\" --> git reset --index HEAD^\n\nI do not think this has a clear meaning. \"discard the last commit but\nleave the contents in the working tree. I do not care a newly added files\nare forgotten by the index, I'll remember to re-add them if I need to\" is\nwhat you are saying here, but the word \"index\" does not hint it. When\nused as an option name, \"--index\" means \"this command usually works on or\ntouches working tree but for this invocation please also affect the index\";\n\"please look at or affect _only_ the index\" is usually spelled \"--cached\".\n\nIn any case, I think your proposal makes it even worse than the current\nstate, and you should aim higher. Some modes of \"git reset\" have\nhistorical reasoning behind their behaviour that cannot be dismissed\neasily by somebody who does not understand them, but at the same time some\nof them outlived their usefulness and we may want to start thinking about\ndeprecating them. The first step might be to make them less prominent in\nthe documentation.\n\nI am guilty of introducing \"git reset --soft HEAD^\" before I invented\n\"commit --amend\" during v1.3.0 timeframe to solve the issue \"soft\" reset\noriginally wanted to. Even though the whole point of the \"reset\" command\nis about \"resetting the index\", it is an unfortunate oddball that does not\ntouch the index. It shouldn't have been part of the \"reset\" command, and\nif we were doing Git from scratch today, we probably wouldn't have it\nthere. What it does is sometimes useful in interactive use and often\nuseful in scripting, but scripts can use update-ref.\n\n\"git reset --hard HEAD\" is an unambiguously descriptive good name for the\noption. It is a \"hard reset\" like power cycling a machinery to discard\nanything in progress and get back to a clean slate. I do not see anything\nconfusing with this mode nor its name.\n\n\"git reset --keep\" was introduced at 9bc454d (reset: add option \"--keep\"\nto \"git reset\", 2010-01-19) as a short-hand to run something like this.\n\n git checkout -B $current_branch $target_commit\n\nIf we made the above command line to work (it errors out saying you cannot\nupdate the current branch) instead of adding it a new mode to \"reset\", it\nwould have been much easier to understand what the particular operation\ndoes. You are updating the tip of the branch that happens to be the\ncurrent branch to a different commit while carrying the local change with\nyou.\n\nIt also would have made number of options \"reset\" has smaller by one and\nreducing confusion. What it does is too similar to what \"reset --merge\"\ndoes, which only adds to the confusion.\n"},{"id":"179922","messageId":"CAGK7Mr5nQoubAw11KDj4WKwQnXrfgteKbMj2=AR-HhsGKi52wQ@mail.gmail.com","threadId":"29005","inReplyTo":"7vlir6brjw.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-11-23T23:00:38Z","receivedAt":"2011-11-23T23:00:38Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> \"I want to discard my changes\" --> git reset --all HEAD^\n>\n> That is discarding your changes and also the last commit.\n\nYes, of course.\n\n\n>> \"I want to discard the last commit\" --> git reset --index HEAD^\n>\n> I do not think this has a clear meaning. \"discard the last commit but\n> leave the contents in the working tree. I do not care a newly added files\n> are forgotten by the index, I'll remember to re-add them if I need to\" is\n> what you are saying here, but the word \"index\" does not hint it.  When\n> used as an option name, \"--index\" means \"this command usually works on or\n> touches working tree but for this invocation please also affect the index\";\n> \"please look at or affect _only_ the index\" is usually spelled \"--cached\".\n\nWell, it's certainly a bit more descriptive and easy to remember than\n\"--mixed\". I understand it could confuse people because of the other\ncommands, but maybe something like \"--index-only\"?\n\n\n> In any case, I think your proposal makes it even worse than the current\n> state, and you should aim higher.\n\nWhy worse? I'd understand if you said it's doesn't improve it enough\nfor it to be worth the change tho.\nAnyway, my proposal was to get a discussion going, and I'm all for\naiming higher if there's a way. What do you propose instead? You\nseemed to imply we'd remove --soft and --merge, and make --keep as an\noption for --hard but named differently, something like\n--keep-changes. Maybe I didn't fully understand.\n\nMathieu even suggested that it'd have the behavior of --keep by\ndefault, and that you have to add --force to get today's --hard\nbehavior, which sounds like a good idea to me (avoid destructive\nbehavior by default).\n\nPhilippe\n"},{"id":"180221","messageId":"CABURp0oAvt4uES1kjqE0OfSiS9DR6Uj+0bf=zgUi5qkw0rqCSQ@mail.gmail.com","threadId":"29005","inReplyTo":"7vlir6brjw.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-01T21:02:09Z","receivedAt":"2011-12-01T21:02:09Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Nov 23, 2011 at 1:51 PM, Junio C Hamano wrote:\n> \"git reset --hard HEAD\" is an unambiguously descriptive good name for the\n> option. It is a \"hard reset\" like power cycling a machinery to discard\n> anything in progress and get back to a clean slate. I do not see anything\n> confusing with this mode nor its name.\n\nAs a git expert-user, I agree.\n\nBut, honestly, as a git new-user, I had a lot of trouble with this\ncommand. It is mysterious and powerful and new users do not\nunderstand it. Everyone learns \"git reset --hard HEAD\" as a single\ncommand. Only much later (if ever) do they learn about the other\ngit-reset options. --hard is the only useful option for the new user,\nso it seems superfluous. HEAD is a foreign concept for the new-user\nand makes little sense when this command is first memorized. And at\nthe early stages of the git learning curve, that's what it is:\nmemorized. _The spelling is what counts; the meaning is mysterious._\n(For all its flaws, though, at least \"git reset --hard HEAD\" serves to\nintroduce the new-user to the concept of HEAD.)\n\nSo, as a git new-user, what I wanted was this:\n git clean-checkout [or \"git checkout --clean\"]\n\nWhat I found instead was this:\n git reset --hard HEAD\n\nWhat does this have to do with \"checking out my files from the last\ncommit\" or \"discarding my local, uncommitted edits\"? To the new-user,\nnothing at all. reset? Meaningless. --hard? Whatever. HEAD?\nShrug.\n\nIn the end it doesn't even do what I wanted. What I really wanted was this:\n git reset --hard HEAD && git clean -fd\n\nI think the git-reset modes should be relegated to plumbing. I can\nsee how 'git reset --mixed' is useful for resetting changes out of the\nindex, but reset is so mired in all sorts of extra mumbo-jumbo that\nthis usage becomes a forgotten detail for me. I didn't even learn\nthat usage until later, where it makes loads of sense on its own:\n\n FTH: This means that git reset is the opposite of git add .\n\nThat is beautiful, clean and useful. If that's all it did, it would be perfect.\n\nProblems with git-reset--hard:\n * It has no safety nets (except the reflog, another concept foreign\nto new-users)\n * It requires extra switches/arguments to be useful\n * Surprisingly (at first), it can move your branch, but it's not\nspelled 'branch' or 'commit' or 'move'\n\nThat last one is particularly troubling in light of the description of\n'git reset --hard':\n Resets the index and working tree. Any changes to tracked\n files in the working tree since are discarded.\n\nMaybe we should add \"and by the way, your currently checked-out branch\nis moved to point to \".\n\n\n\nPhil\n"},{"id":"180222","messageId":"CABURp0rtCUbJXLHtXv_1g6GRKL3mX-T+3vN1=QO4CUibqXdEMg@mail.gmail.com","threadId":"29005","inReplyTo":"CAGK7Mr5nQoubAw11KDj4WKwQnXrfgteKbMj2=AR-HhsGKi52wQ@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-01T21:23:57Z","receivedAt":"2011-12-01T21:23:57Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Nov 23, 2011 at 6:00 PM, Philippe Vaucher\n wrote:\n>> In any case, I think your proposal makes it even worse than the current\n>> state, and you should aim higher.\n>\n> Why worse? I'd understand if you said it's doesn't improve it enough\n> for it to be worth the change tho.\n\nI think that's what \"you should aim higher\" means.\n\n> Anyway, my proposal was to get a discussion going, and I'm all for\n> aiming higher if there's a way. What do you propose instead? You\n> seemed to imply we'd remove --soft and --merge, and make --keep as an\n> option for --hard but named differently, something like\n> --keep-changes. Maybe I didn't fully understand.\n\nI think there are too many scripts dependent on these switches to\nremove them. But I love the direction you're going in.\n\nAim higher.\n\n> Mathieu even suggested that it'd have the behavior of --keep by\n> default, and that you have to add --force to get today's --hard\n> behavior, which sounds like a good idea to me (avoid destructive\n> behavior by default).\n\nThink outside the \"reset\" command. Like this:\n\n>From the \"most popular\" comment on http://progit.org/2011/07/11/reset.html:\n> I remember them as:\n> --soft -> git uncommit\n> --mixed -> git unadd\n> --hard -> git undo\n\nI don't particular like these names, but conceptually they are helpful.\n\nWhat other commands can we embellish or create to replace the overload\ngit-reset functionality?\n\nHow about:\n --soft: git checkout -B \n --mixed: git reset -- \n --hard: git checkout --clean\n\nPhil\n"},{"id":"180238","messageId":"201112020826.14114.trast@student.ethz.ch","threadId":"29005","inReplyTo":"CABURp0rtCUbJXLHtXv_1g6GRKL3mX-T+3vN1=QO4CUibqXdEMg@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-12-02T07:26:13Z","receivedAt":"2011-12-02T07:26:13Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Phil Hord wrote:\n> \n> Think outside the \"reset\" command. Like this:\n> \n> From the \"most popular\" comment on http://progit.org/2011/07/11/reset.html:\n> > I remember them as:\n> > --soft -> git uncommit\n> > --mixed -> git unadd\n> > --hard -> git undo\n> \n> I don't particular like these names, but conceptually they are helpful.\n\nI think all of these, but the last one in particular, are *very*\ndangerous oversimplifications. Doubly so if you then use \"undo\" with\na revision argument.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"180239","messageId":"buowrafxvq9.fsf@dhlpc061.dev.necel.com","threadId":"29005","inReplyTo":"201112020826.14114.trast@student.ethz.ch","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-12-02T07:45:34Z","receivedAt":"2011-12-02T07:45:34Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Thomas Rast writes:\n>> > I remember them as:\n>> > --soft -> git uncommit\n>> > --mixed -> git unadd\n>> > --hard -> git undo\n>> \n>> I don't particular like these names, but conceptually they are helpful.\n>\n> I think all of these, but the last one in particular, are *very*\n> dangerous oversimplifications. Doubly so if you then use \"undo\" with\n> a revision argument.\n\nI agree. Not only is it completely wrong when used with a revision\nargument, but \"undo\" is so vague that it's probably useless for _any_\ngit command, much less one so dangerous as \"reset --hard\".\n\n-miles\n\n-- \nFriendship, n. A ship big enough to carry two in fair weather, but only one\nin foul.\n"},{"id":"180248","messageId":"CAGK7Mr7zdstbm7QsrYq9a6m9ui_r8Ak8XtyWADLQ0n-mXiov4w@mail.gmail.com","threadId":"29005","inReplyTo":"CABURp0rtCUbJXLHtXv_1g6GRKL3mX-T+3vN1=QO4CUibqXdEMg@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-12-02T14:27:13Z","receivedAt":"2011-12-02T14:27:13Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> > Why worse? I'd understand if you said it's doesn't improve it enough\n> > for it to be worth the change tho.\n>\n> I think that's what \"you should aim higher\" means.\n\nYes, but my question was why was the proposal _worse_ in his mind.\nAnyway, it's not really important, probably something he typed in a\nhurry.\n\n\n> How about:\n>  --soft: git checkout -B \n>  --mixed: git reset -- \n>  --hard:  git checkout --clean\n\nI like the idea... but as other pointed out those are not equivalent.\n\nMaybe we'd start by listing the features we want to be able to do:\n\n- Move git's HEAD to a particular commit without touching the files or the index\n- Move git's HEAD to a particular commit and clear the index but\nwithout touching the files\n- Move git's HEAD to a particular commit and clear the index and have\nall the files match that particular commit files\n- Move git's HEAD to a particular commit and clear the index and have\nall the files match that particular commit files and remove files that\nare unknown to that commit\n\nIs there a scenario I'm missing? Once we have the scenarios nailed\ndown we can start thinking about how to express them.\n\nPhilippe\n"},{"id":"180250","messageId":"CABURp0qcHaoi58EQ1FLGo2atPuWfS5x4p_SK7ZA_AqV7as212w@mail.gmail.com","threadId":"29005","inReplyTo":"201112020826.14114.trast@student.ethz.ch","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-02T15:28:08Z","receivedAt":"2011-12-02T15:28:08Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Dec 2, 2011 at 2:26 AM, Thomas Rast wrote:\n> Phil Hord wrote:\n>>\n>> Think outside the \"reset\" command.  Like this:\n>>\n>> From the \"most popular\" comment on http://progit.org/2011/07/11/reset.html:\n>> > I remember them as:\n>> > --soft      -> git uncommit\n>> > --mixed  -> git unadd\n>> > --hard     -> git undo\n>>\n>> I don't particular like these names, but conceptually they are helpful.\n>\n> I think all of these, but the last one in particular, are *very*\n> dangerous oversimplifications.  Doubly so if you then use \"undo\" with\n> a revision argument.\n\nI agree. That's why I also said this:\n\n> How about:\n> --soft: git checkout -B \n> --mixed: git reset -- \n> --hard: git checkout --clean\n\nBut maybe I wasn't clear enough. I'm not suggesting git-alias for\nthese. I am proposing new commands to replace common usages of\ngit-reset. These commands would need basic safeguards against\nfoot-shooting, of course.\n\nPhil\n"},{"id":"180251","messageId":"CABURp0pmnsgE1ywW-W2+QFNci=3Lm=JKj9Y3U8zjh8+Cg_NA6Q@mail.gmail.com","threadId":"29005","inReplyTo":"CAGK7Mr7zdstbm7QsrYq9a6m9ui_r8Ak8XtyWADLQ0n-mXiov4w@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-02T15:38:05Z","receivedAt":"2011-12-02T15:38:05Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Dec 2, 2011 at 9:27 AM, Philippe Vaucher\n wrote:\n> Maybe we'd start by listing the features we want to be able to do:\n>\n> - Move git's HEAD to a particular commit without touching the files or the index\n> - Move git's HEAD to a particular commit and clear the index but\n> without touching the files\n> - Move git's HEAD to a particular commit and clear the index and have\n> all the files match that particular commit files\n> - Move git's HEAD to a particular commit and clear the index and have\n> all the files match that particular commit files and remove files that\n> are unknown to that commit\n>\n> Is there a scenario I'm missing? Once we have the scenarios nailed\n> down we can start thinking about how to express them.\n\nAim higher.\n\nDo not think about the git-reset command and all of its features.\nMoreover, do not limit yourself to git-reset's functionality.\n\nThink about why you need to use git-reset. Why do new users need to\nuse git-reset? What is it they are after?\n\nFor me, it was the three I mentioned before.\n\nSo, let's look at yours:\n\n> - Move git's HEAD to a particular commit without touching the files or the index\n\nI know what this is, but I don't know to describe it without saying\n\"reset\". It's like teleportation. \"Move me to a new location in the\ntree\".\ngit teleport \n\n\n> - Move git's HEAD to a particular commit and clear the index but\n> without touching the files\n\ngit teleport --index \n\n\n> - Move git's HEAD to a particular commit and clear the index and have\n> all the files match that particular commit files\n\ngit checkout --clean \n\n\n> - Move git's HEAD to a particular commit and clear the index and have\n> all the files match that particular commit files and remove files that\n> are unknown to that commit\n\ngit checkout --clean && git clean -fd # maybe this needs a switch?\n\n\nOne you left out is this:\n- Do NOT move git's HEAD; clear the index and workdir\n\ngit reset\n\n\nI think the ability to move git's HEAD is what makes reset dangerous,\nespecially in the hands of new users.\n\nPhil\n"},{"id":"180360","messageId":"CAGK7Mr7+_n4opf=uQARxA7iSUMFNn9GCFGD5TrhCgarwGhEySA@mail.gmail.com","threadId":"29005","inReplyTo":"CABURp0pmnsgE1ywW-W2+QFNci=3Lm=JKj9Y3U8zjh8+Cg_NA6Q@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-12-06T07:34:59Z","receivedAt":"2011-12-06T07:34:59Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> Think about why you need to use git-reset.  Why do new users need to\n> use git-reset?  What is it they are after?\n\nOk, so let's forget about git reset and let's focus on the features\ninstead. If I got it right you suggested the features that people\nwants most often are uncommit, unadd/undelete and undo. Here's a new\nproposal (based on your input):\n\nuncommit: git jump (currently \"git reset --soft \")\nunadd/undelete: git unstage file (currently \"git reset --mixed file\"\n(with \"git checkout file\" for deleted files)\nundo: git checkout --force --clean (currently \"git reset\n--hard && git clean -fd\")\n\nSo, let's try out some scenarios:\n\n1) Newbie user clones/pulls a repository from somewhere. He hacks\naround and then things go bad, and he decides to scratch away\neverything he did to make sure things are like they're supposed to be.\nHe'd then type \"git checkout --force --clean master\". If he didn't\nintroduce new files, he would simply type \"git checkout --force\nmaster\"\n\n2) Newbie adds some file to the index, then realise he added one too\nmany. He wants to remove it from being added. He'd then type \"git\nunstage file\".\n\n3) Average user creates a commit and suddenly realise he actually\nwanted to split that commit in two (he cannot use --amend, and he's\nnot a rebase -i guru yet). Or he did a \"temp\" commit because he don't\nknow about \"git stash\" yet and wants to discard it. He wants to simply\ngo back to the previous state while keeping his changes in the index\nand the worktree. He'd then type \"git jump HEAD^1\".\n\nFeel free to add more scenarios!\n\nPhilippe\n"},{"id":"200431","messageId":"CABURp0rho3KvzHRNXj9EA9C2OnbTc_dcmiBiW6JZ-VHu4g2m0Q@mail.gmail.com","threadId":"29005","inReplyTo":"CAGK7Mr7+_n4opf=uQARxA7iSUMFNn9GCFGD5TrhCgarwGhEySA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-10-03T16:23:42Z","receivedAt":"2012-10-03T16:23:42Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Dec 6, 2011 at 2:34 AM, Philippe Vaucher\n wrote:\n>> Think about why you need to use git-reset. Why do new users need to\n>> use git-reset? What is it they are after?\n>\n> Ok, so let's forget about git reset and let's focus on the features\n> instead. If I got it right you suggested the features that people\n> wants most often are uncommit, unadd/undelete and undo. Here's a new\n> proposal (based on your input):\n\nI flagged this for followup in my MUA, but I failed to follow-up after\nthe holidays. I apologize for that, and I really regret it because I\nliked where this was going. I only remembered it today when it came\nup again in another thread.\n\n> uncommit: git jump (currently \"git reset --soft \")\n> unadd/undelete: git unstage file (currently \"git reset --mixed file\"\n> (with \"git checkout file\" for deleted files)\n> undo: git checkout --force --clean (currently \"git reset\n> --hard && git clean -fd\")\n>\n> So, let's try out some scenarios:\n>\n> 1) Newbie user clones/pulls a repository from somewhere. He hacks\n> around and then things go bad, and he decides to scratch away\n> everything he did to make sure things are like they're supposed to be.\n> He'd then type \"git checkout --force --clean master\". If he didn't\n> introduce new files, he would simply type \"git checkout --force\n> master\"\n\nI like this just fine. I think we can explicitly say that HEAD is the\nimplied default refspec, yes? \"git checkout --force --clean\"\n\n> 2) Newbie adds some file to the index, then realise he added one too\n> many. He wants to remove it from being added. He'd then type \"git\n> unstage file\".\n\nI'm afraid of the word \"stage\" because of previous discussions about\nits i18n abilities. How about \"unadd\" and \"unrm\"? Or maybe \"git undo\nadd\", \"git undo rm\" and \"git undo commit\".\n\nThe fact that \"git undo rm $FILE\" works the same as \"git checkout HEAD\n-- $FILE\" and does not truly \"undo\" the delete operation may make this\na non-starter. And I admit I have other qualms about using \"undo\"\neven though I keep on introducing it into the discussion. For\nexample, this hypothetical sequence will do what I expect when I read\nit:\n\n cp bar foo\n git add foo\n echo \"more info\" >> foo\n git add foo\n git unstage foo # now index:foo == HEAD:foo\n\nBut if I use \"git undo add\", it will not\n\n cp bar foo\n git add foo\n echo \"more info\" >> foo\n git add foo\n git undo add foo # index:foo == HEAD:foo, not index:foo == bar\n\nDang.\n\nWell, I personally am ok with 'unstage' but I expect others will not be.\n\n> 3) Average user creates a commit and suddenly realise he actually\n> wanted to split that commit in two (he cannot use --amend, and he's\n> not a rebase -i guru yet). Or he did a \"temp\" commit because he don't\n> know about \"git stash\" yet and wants to discard it. He wants to simply\n> go back to the previous state while keeping his changes in the index\n> and the worktree. He'd then type \"git jump HEAD^1\".\n\nI fear the HEAD^1 concept is too much for the newbie. What about \"git\nuncommit [$REF]\" instead? It would work like \"git reset --soft\n$REF^\", I think, but maybe it should fail if $REF has multiple\nparents.\n\nIf the user really wants to uncommit a merge commit, she may need to\nuse \"git unmerge\".\n\nPhil\n"},{"id":"200441","messageId":"7v391v5rgb.fsf@alter.siamese.dyndns.org","threadId":"29005","inReplyTo":"CABURp0rho3KvzHRNXj9EA9C2OnbTc_dcmiBiW6JZ-VHu4g2m0Q@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-03T18:41:08Z","receivedAt":"2012-10-03T18:41:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord writes:\n\n> I flagged this for followup in my MUA, but I failed to follow-up after\n> the holidays. I apologize for that, and I really regret it because I\n> liked where this was going.\n\nI really regret to see you remembered it, actually.\n\n>> 1) Newbie user clones/pulls a repository from somewhere. He hacks\n>> around and then things go bad, and he decides to scratch away\n>> everything he did to make sure things are like they're supposed to be.\n>> He'd then type \"git checkout --force --clean master\". If he didn't\n>> introduce new files, he would simply type \"git checkout --force\n>> master\"\n>\n> I like this just fine. I think we can explicitly say that HEAD is the\n> implied default refspec, yes? \"git checkout --force --clean\"\n\nThat depends on what the \"hacks around\" involved. Where is he now,\nwhat damage did he cause, and what can you depend on to take him to\na \"clean\" state, where the definition of \"clean\" happens to match\nthis hypothetical \"Newbie user\"? Did he do \"git checkout\" of\nanother branch? Did he commit? Did he \"reset\" to other commit\nwhile on the 'master' branch? Is he still on \"master\" branch when\nhe says \"git checkout --force --clean \"? Can he say \"git\ncheckout --force --clean master~4\" and what does that even mean? Is\nhe trying to go into the detached HEAD state, or is he somehow\ntrying to rewind master?\n"},{"id":"200445","messageId":"7vhaqb4bvb.fsf@alter.siamese.dyndns.org","threadId":"29005","inReplyTo":"7v391v5rgb.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-03T19:03:04Z","receivedAt":"2012-10-03T19:03:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Phil Hord writes:\n>\n>> I flagged this for followup in my MUA, but I failed to follow-up after\n>> the holidays. I apologize for that, and I really regret it because I\n>> liked where this was going.\n>\n> I really regret to see you remembered it, actually.\n\nHaving said that, I am glad that you brought the old discussion\nthread to our attention. In\n\n http://thread.gmane.org/gmane.comp.version-control.git/185825/focus=185863,\n\nI said that \"git reset --keep\" started out as an ugly workaround for\nthe lack of \"git checkout -B $current_branch\". Now we have it, so\nwe can afford to make \"reset --keep\" less prominently advertised in\nour tool set. As I already said back then, \"reset --soft\" also has\noutlived its usefulness when \"commit --amend\" came, so that leaves\nonly these modes of \"reset\":\n\n reset --hard [$commit]\n\treset [$commit]\n reset --merge\n\nI am not sure if it makes sense to give a commit different from HEAD\nto \"reset --merge\", and to a lessor degree, \"reset --mixed\" to flip\nthe HEAD to another commit while retaining the working tree contents\ndoes not make much sense, either, in a common workflow.\n\nIt _might_ be possible to merge the --mixed and --merge if we think\nthings through to reduce the often-used options even further, but I\nhaven't done so, and I suspect nobody has (yet).\n"},{"id":"204935","messageId":"alpine.LNX.2.01.1212151955330.14667@nerf07.vanv.qr","threadId":"29005","inReplyTo":"7vhaqb4bvb.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2012-12-15T18:57:57Z","receivedAt":"2012-12-15T18:57:57Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Wednesday 2012-10-03 21:03, Junio C Hamano wrote:\n>\n>I said that \"git reset --keep\" started out as an ugly workaround for\n>the lack of \"git checkout -B $current_branch\". Now we have it, so\n>we can afford to make \"reset --keep\" less prominently advertised in\n>our tool set. As I already said back then, \"reset --soft\" also has\n>outlived its usefulness when \"commit --amend\" came, so that leaves\n>only these modes of \"reset\":\n\nSoft is still useful, partway. Consider patch splitting (where easily\npossible):\n\n $ git add foo.c bar.c\n $ git commit -m foo,bar\n [other commits]\n $ git rebase -i FOOBARCOMMIT^\n [mark foo,bar for edit]\n $ git reset --soft HEAD^\n $ git reset bar.c\n $ git commit -m foo\n $ git add bar.c\n $ git commit -m bar\n $ git rebase --continue\n"},{"id":"205108","messageId":"CANiSa6ioKVo5VHht_5R4YwQOoWK8rXPLVFTqMq8J-jBEe2OaRA@mail.gmail.com","threadId":"29005","inReplyTo":"vpq4nxvusty.fsf@bauges.imag.fr","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2012-12-18T06:24:53Z","receivedAt":"2012-12-18T06:24:53Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy\n wrote:\n> Philippe Vaucher writes:\n>\n>> Optional: a new mode would be introduced for consistency:\n>> --worktree (or maybe --tree): only updates the worktree but not the index\n>\n> That would be an alias for \"git checkout -- path\", right?\n\nNot quite, in two ways, I think. First, it _would_ update the index,\nwouldn't it? Second, \"git checkout -- path\" doesn't delete files\nthat are deleted in as compared to head.\n\nI'm considering implementing support for an operation that would do\nwhat I expected \"git checkout -- \" and \"git reset --hard\n -- \" to do. I'm currently planning for it to be exactly\n\"git reset --hard -- \" (which is currently simply not\nallowed), but perhaps it would be more natural as an option to\ncheckout (--also-deleted or something)?\n"},{"id":"205109","messageId":"CANiSa6h3Qf=6hw6fzHVw=CeuhnNeq+cuEvwwmVhUaSOcVgCSBA@mail.gmail.com","threadId":"29005","inReplyTo":"7vlir6brjw.fsf@alter.siamese.dyndns.org","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2012-12-18T06:34:07Z","receivedAt":"2012-12-18T06:34:07Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano wrote:\n>\n> I am guilty of introducing \"git reset --soft HEAD^\" before I invented\n> \"commit --amend\" during v1.3.0 timeframe to solve the issue \"soft\" reset\n> originally wanted to.\n\nI do use \"commit --amend\" a lot, but I still appreciate having \"reset\n--soft\". For example, to squash the last few commits:\n\ngit reset --soft HEAD^^^ && git commit --amend\n\nor undo \"commit --amend\":\n\ngit reset --soft HEAD@{1} && git commit --amend\n\nMaybe there's a better way of doing that?\n"},{"id":"205123","messageId":"7vk3sfidvz.fsf@alter.siamese.dyndns.org","threadId":"29005","inReplyTo":"CANiSa6h3Qf=6hw6fzHVw=CeuhnNeq+cuEvwwmVhUaSOcVgCSBA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-18T15:22:24Z","receivedAt":"2012-12-18T15:22:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin von Zweigbergk writes:\n\n> On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano wrote:\n>>\n>> I am guilty of introducing \"git reset --soft HEAD^\" before I invented\n>> \"commit --amend\" during v1.3.0 timeframe to solve the issue \"soft\" reset\n>> originally wanted to.\n>\n> I do use \"commit --amend\" a lot, but I still appreciate having \"reset\n> --soft\". For example, to squash the last few commits:\n>\n> git reset --soft HEAD^^^ && git commit --amend\n\nYeah, I do that sometimes myself, but the key word is \"sometimes\".\nThese days, I think most users (not just mortals but experienced\nones) use \"rebase -i\" to squash them altogether, either with \"fixup\",\nwith which you lose the messages from the follow-up fixes, just\nlike the soft reset to an old one with an amen,) or with \"squash\",\nwith which you can pick pieces of messages from the follow-up fixes\nwhile updating the message from the original one.\n"},{"id":"205129","messageId":"20121218163057.GB20122@sigill.intra.peff.net","threadId":"29005","inReplyTo":"CANiSa6h3Qf=6hw6fzHVw=CeuhnNeq+cuEvwwmVhUaSOcVgCSBA@mail.gmail.com","subject":"Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-12-18T16:30:57Z","receivedAt":"2012-12-18T16:30:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote:\n\n> On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano wrote:\n> >\n> > I am guilty of introducing \"git reset --soft HEAD^\" before I invented\n> > \"commit --amend\" during v1.3.0 timeframe to solve the issue \"soft\" reset\n> > originally wanted to.\n> \n> I do use \"commit --amend\" a lot, but I still appreciate having \"reset\n> --soft\". For example, to squash the last few commits:\n> \n> git reset --soft HEAD^^^ && git commit --amend\n\nMe too. Another one I use is:\n\n $ hack hack hack\n $ git commit -m wip\n $ git checkout something-else\n ... time passes ...\n $ git checkout orig-branch\n $ git reset --soft HEAD^\n $ hack hack hack\n $ git diff\n $ git add -p\n $ git commit\n\nwhich ends up with the same history as \"commit --amend\", but in between\nthe reset and the commit, the bogus WIP commit is thrown away entirely.\nAnd things like \"diff\" and \"add -p\" do what you want, instead of showing\nyour progress on top of the WIP.\n\n-Peff\n"}]}