Subject: Re: Undo last commit?

From: Massimo Manca <[email-masked]>
Date: Mon, 20 Jun 2011 14:08:10 +0200

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 <[email-masked]> 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'.
>