Re: Undo last commit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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'.
 
-- 
Jakub Narebski
Poland
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]