I've created a 'wrapper' for git which stops me from making dumb mistakes, it is working really well so far. I will add your ideas to it... thanks! I do think that git needs polishing in this way. It was designed by a very intelligent programmer... however they can sometimes be the worst at user interface design. I think a lot of people are missing out on how great git is because of the learning curve, and also the slightly odd naming conventions. "git reset --soft HEAD^" can't be picked up that quickly by a beginner, but git uncommit would be obvious! So I have to agree with Holger. Good design makes something intuitive. I have used DVD recorder / players that are so badly designed that I needed to read the instruction manual. Something complicated can be designed to such a degree that people rarely have to read a manual, and they can pick it up really quickly because it's obvious. If you disagree then you might need to learn something about good design because what I say isn't opinion it's a fact. Flame away :) Apologies for stereotyping! On 28 June 2011 14:57, Holger Hellmuth <hellmuth@xxxxxxxxxx> wrote: > Let me play devils advocate: > Wouldn't it be nice to have a command 'git uncommit' (in core git) that > would be an alias to "git reset --keep HEAD^" ? And if not already done, it > should hint at "git reset --soft HEAD^" in case of failure because of > conflicts. > > It would be a nice companion to the not-yet-realized "git unadd" ;-) > > Holger. > > > On 20.06.2011 14:08, Massimo Manca wrote: >> >> Hello, >> I several times made the mistake of a wrong commit also if generally the >> error born for a wrong add expecially: >> >> git add . in a directory with some files that haven't to be managed by >> git. >> >> So, as wrote in some emails here, if I wrote something like: >> git commit -m "Added file.c" -a >> >> I tryed to solve with: >> git commit --amend -m "Added file.c" -a >> >> hoping to have a status like before the commit and then sending: >> git reset . >> >> hoping to have a status like that before the wrong add. >> But this is not what git status say so, my solution to solve commi >> problems is ALWAYS: >> >> git reset --soft HEAD^ >> >> that for my point of view works better then all others permitting to >> redo last add and commit to solve not only a -m problem but also a wrong >> git add command. >> >> Il 19/06/2011 12.37, Jakub Narebski ha scritto: >>> >>> On Sun, 19 Jun 2011, Jonathan Nieder wrote: >>>> >>>> Jakub Narebski wrote: >>>>> >>>>> Mike<xandrani@xxxxxxxxx> writes: >>>>>> >>>>>> % git reset --hard HEAD~1 >>>>> >>>>> Errr... here you screwed up. This reset state of you working area to >>>>> the state at last commit, removing all your changes to tracked files. >>>> >>>> Or rather, here we screwed up. Jakub and others gave some useful >>>> advice about how to recover, so let's consider how the UI or >>>> documentation could be improved to prevent it from happening again. >>>> >>>> * In this example if I understand correctly then the index contained >>>> some useful information, perhaps about a larger commit intended for >>>> later. To preserve that, you could have used >>>> >>>> git reset --soft HEAD~1 >>>> >>>> which would _just_ undo the effect of "git commit", leaving the index >>>> and worktree alone. >>> >>> Another issue is that Mike haven't realized that `--amend' option can be >>> used *in combination* with other "git commit" options, which means that >>> the solution to his problem was using "git commit" as it should have >>> been done, but with '--amend' added. >>> >>> I'm not sure if git documentation talks about 'git reset --soft HEAD^', >>> and when to use it; from what I remember it encourages use of >>> 'git commit --amend' instead (which was I guess most often used reason >>> of using soft reset before there was '--amend'). >>> >>>> * Another situation that comes up from time to time is making a change >>>> that just turned out to be a bad idea. After commiting it, you might >>>> want to discard the erroneous change, like so: >>>> >>>> git reset --keep HEAD~1 >>>> >>>> The "--keep" option uses some safeguards to make sure that only the >>>> committed change gets discarded, instead of clobbering local changes >>>> at the same time. >>>> >>>> * In the early days of git, the "--keep" option did not exist. So a lot >>>> of old documentation recommends to do >>>> >>>> git reset --hard HEAD~1 >>>> >>>> which is the same if you don't have any local changes. >>> >>> Yes, it would be good idea to examine git documentation (tutorials, >>> user's manual, manpages, perhaps "Git Community Book" and "Pro Git" >>> too) to encourage use of new safer options of hard reset, namely >>> '--keep' and '--merge' instead of '--hard'. >>> >> > > -- 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