Re: Undo last commit?

[Holger Hellmuth <hellmuth@ira.uka.de>]

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@gmail.com>  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'.
>>
>