On Tue, Dec 6, 2011 at 2:34 AM, Philippe Vaucher <philippe.vaucher@xxxxxxxxx> wrote: >> Think about why you need to use git-reset. Why do new users need to >> use git-reset? What is it they are after? > > Ok, so let's forget about git reset and let's focus on the features > instead. If I got it right you suggested the features that people > wants most often are uncommit, unadd/undelete and undo. Here's a new > proposal (based on your input): I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I only remembered it today when it came up again in another thread. > uncommit: git jump <commit> (currently "git reset --soft <commit>") > unadd/undelete: git unstage file (currently "git reset --mixed file" > (with "git checkout file" for deleted files) > undo: git checkout --force --clean <commit> (currently "git reset > --hard <commit> && git clean -fd") > > So, let's try out some scenarios: > > 1) Newbie user clones/pulls a repository from somewhere. He hacks > around and then things go bad, and he decides to scratch away > everything he did to make sure things are like they're supposed to be. > He'd then type "git checkout --force --clean master". If he didn't > introduce new files, he would simply type "git checkout --force > master" I like this just fine. I think we can explicitly say that HEAD is the implied default refspec, yes? "git checkout --force --clean" > 2) Newbie adds some file to the index, then realise he added one too > many. He wants to remove it from being added. He'd then type "git > unstage file". I'm afraid of the word "stage" because of previous discussions about its i18n abilities. How about "unadd" and "unrm"? Or maybe "git undo add", "git undo rm" and "git undo commit". The fact that "git undo rm $FILE" works the same as "git checkout HEAD -- $FILE" and does not truly "undo" the delete operation may make this a non-starter. And I admit I have other qualms about using "undo" even though I keep on introducing it into the discussion. For example, this hypothetical sequence will do what I expect when I read it: cp bar foo git add foo echo "more info" >> foo git add foo git unstage foo # now index:foo == HEAD:foo But if I use "git undo add", it will not cp bar foo git add foo echo "more info" >> foo git add foo git undo add foo # index:foo == HEAD:foo, not index:foo == bar Dang. Well, I personally am ok with 'unstage' but I expect others will not be. > 3) Average user creates a commit and suddenly realise he actually > wanted to split that commit in two (he cannot use --amend, and he's > not a rebase -i guru yet). Or he did a "temp" commit because he don't > know about "git stash" yet and wants to discard it. He wants to simply > go back to the previous state while keeping his changes in the index > and the worktree. He'd then type "git jump HEAD^1". I fear the HEAD^1 concept is too much for the newbie. What about "git uncommit [$REF]" instead? It would work like "git reset --soft $REF^", I think, but maybe it should fail if $REF has multiple parents. If the user really wants to uncommit a merge commit, she may need to use "git unmerge". Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html