Undo last commit?

Undo last commit?

[Mike]

Hi fellow gitters,

I have performed a 'git commit' on all 'added' files by mistake and
now I want to undo this commit to return to the original state. Here's
a more detailed description:


1. I did a 'git status' and there were files which I had 'added' ready
for a commit. There were also some changes that had not been 'added'
yet. See below:

% git status
# On branch master
# Your branch is ahead of 'origin/master' by 7 commits.
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   cgi-bin/example1.php
#	modified:   cgi-bin/example2.php
#	modified:   example3.php
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   cgi-bin/example4.php
#	modified:   example5.php
#


2. I accidentally did a commit for ALL files because I forgot to
specify the filename at the end of the commit.
e.g. instead of 'commit -m "commit message" example3.php' I did
'commit -m "commit message"'.

3. I googled the problem and it seems everyone has a different way of
doing this. (Maybe git is too confusing if everyone has different
methods that all work slightly differently!?). Anyway I executed this
command:

% git commit --amend

But I aborted this by exiting my text editor.

4. I then tried:

% git reset --hard HEAD~1

5. However now when I do a 'git status' none of the files that were
original listed are there. A git status now gives this:

# On branch master
# Your branch is ahead of 'origin/master' by 7 commits.
#
nothing to commit (working directory clean)


Any ideas how to rectify this issue? I presume the 'git commit
--amend' just changes the commit message? I daren't try anything else
myself in case I make matters worse.

Mike

Re: Undo last commit?

[Ben Walton]

Excerpts from Mike's message of Sat Jun 18 09:15:49 -0400 2011:

Hi Mike,

> 3. I googled the problem and it seems everyone has a different way of
> doing this. (Maybe git is too confusing if everyone has different
> methods that all work slightly differently!?). Anyway I executed this
> command:
> 
> % git commit --amend

This command lets you modify the last commit by either adding/removing
changes which you build up with git add or in the case where you've
not staged anything, simply edit the commit message.

> % git reset --hard HEAD~1

What you wanted was:

git reset HEAD^
or
git reset HEAD~1

The --hard resets your working tree to match that commit exactly,
throwing away uncommitted changes.  In your case, it threw away the
unstaged changes you'd made and the last commit.  You should be able
to salvage your last commit by:

git reset ORIG_HEAD

The stuff that had never been git added is likely lost.  Because git
had never created an object for those changes, there won't be much to
work with.

You might inspect the output of git reflog to see if that's of any
value, but I don't think it will be in your case.

> Any ideas how to rectify this issue? I presume the 'git commit
> --amend' just changes the commit message? I daren't try anything else
> myself in case I make matters worse.

As always, take a snapshot of the .git directory before doing further
mucking.  Maybe one of the git gurus here has ideas about the trashed
unstaged changes...?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

Re: Undo last commit?

[Ramkumar Ramachandra]

Hi Mike,

Mike writes:
> I have performed a 'git commit' on all 'added' files by mistake and
> now I want to undo this commit to return to the original state. Here's
> a more detailed description:

In your situation, the "correct" answer is (arguably) 'git reset
HEAD~1'.  This is called a mixed reset (see git-reset(1) for more).

> 2. I accidentally did a commit for ALL files because I forgot to
> specify the filename at the end of the commit.
> e.g. instead of 'commit -m "commit message" example3.php' I did
> 'commit -m "commit message"'.

Ideally, you should only stage what you want to commit.  Isn't that
the reason we have a staging area?

> % git commit --amend

Remember that 'git commit --amend' behaves a lot like 'git commit'; it
commits your staged changes.  Except, instead of making a new commit,
it adds those changes to your previous commit*.  It _additionally_
gives you the ability to update the commit message -- when you tried
it without any staged changes, that's what you saw.  Anyway, this is
not a good option in your particular case;  you'd essentially have to
stage the inverse of all the changes you didn't intend to make in the
previous commit before amending the previous commit.

> % git reset --hard HEAD~1

Ouch.  I'm sorry to have to be the one to give you the bad news; the
changes that you didn't commit (the "unstaged changes" you showed) are
lost forever**.  This is quite a dangerous command, and must be used
with care.

> Any ideas how to rectify this issue? I presume the 'git commit
> --amend' just changes the commit message? I daren't try anything else
> myself in case I make matters worse.

First, you must find the commit you made in the reflog and cherry-pick
it.  See git-reflog(1) and git-cherry-pick(1).  Now you've essentially
undo the hard reset, sans your unstaged changes.  Perform a 'git reset
HEAD~1' to move your HEAD back one step, stage the correct changes
before creating new commits.  A series of commands:
$ git reflog
# Look for the commit you made before; let's call this b8bb3f
$ git cherry-pick b8bb3f
# Stage, unstage whatever you like
$ git commit

* Git never actually loses your commits unless you garbage collect, so
you can still find the old commit (the one that you amended to
originally)
** Okay, very difficult to recover.  You'll have to find the tree
object corresponding to that index state.

-- Ram

Re: Undo last commit?

[Jakub Narebski]

Mike <xandrani@gmail.com> writes:

> Hi fellow gitters,
> 
> I have performed a 'git commit' on all 'added' files by mistake and
> now I want to undo this commit to return to the original state. Here's
> a more detailed description:
> 
> 
> 1. I did a 'git status' and there were files which I had 'added' ready
> for a commit. There were also some changes that had not been 'added'
> yet. See below:
> 
> % git status
> # On branch master
> # Your branch is ahead of 'origin/master' by 7 commits.
> #
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #	modified:   cgi-bin/example1.php
> #	modified:   cgi-bin/example2.php
> #	modified:   example3.php
> #
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #	modified:   cgi-bin/example4.php
> #	modified:   example5.php
> #
> 
> 
> 2. I accidentally did a commit for ALL files because I forgot to
> specify the filename at the end of the commit.
> e.g. instead of 'commit -m "commit message" example3.php' I did
> 'commit -m "commit message"'.

You committed all staged changes (i.e. only those on "Changes to be
committed" list), not all changes; for that you would need to use '-a'
option to git commit.

BTW. why are you using '-m' option?
 
> 3. I googled the problem and it seems everyone has a different way of
> doing this. (Maybe git is too confusing if everyone has different
> methods that all work slightly differently!?). Anyway I executed this
> command:
> 
> % git commit --amend

You could simply use

  % git commit --amend -m "commit message" example3.php

The `--amend` just means to fix (redo) last commit.

> But I aborted this by exiting my text editor.

O.K.

> 4. I then tried:
> 
> % 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.

> 5. However now when I do a 'git status' none of the files that were
> original listed are there. A git status now gives this:
> 
> # On branch master
> # Your branch is ahead of 'origin/master' by 7 commits.
> #
> nothing to commit (working directory clean)
> 
> 
> Any ideas how to rectify this issue? I presume the 'git commit
> --amend' just changes the commit message? I daren't try anything else
> myself in case I make matters worse.

You lost your changes to files on "Changed but not updated" list,
i.e. cgi-bin/example4.php and example5.php.

What you can do is go back to your last commit (the errorneous one) by
using

  $ git reset --keep HEAD@{1}

Which means reset to last state (before 'git reset --hard HEAD~1'; you
can check it with "git reflog" or "git log -g"), keeping your local
changes (if you used '--keep' not '--hard' then you wouldn't loose
your changes).

Then redo this commit like you wanted to

  $ git commit --amend -m "commit message" example3.php

Or better

  $ git commit --amend -v example3.php

To check if you are committing correct changes.

...................

Alternatively check out state of example3.php from last made commit:

  $ git checkout HEAD@{1} -- example3.php

Do your commit

  $ git commit -m "commit message" example3.php

Get state of other files that you accidentally comitted from next to
last state of HEAD:

  $ git checkout HEAD@{2} -- cgi-bin/example1.php cgi-bin/example2.php

Unfortunately changes to cgi-bin/example4.php and example5.php are
lost.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Undo last commit?

[Jonathan Nieder]

Hi,

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 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.

It would be useful to fix such documentation by adding a few words
about local changes.  Recently Duy wrote a patch to improve "reset -h"
output in that vein, but discussion drifted off:

 http://thread.gmane.org/gmane.comp.version-control.git/170266

I also sent a couple of documentation patches and then dropped the
ball:

 http://thread.gmane.org/gmane.comp.version-control.git/165358
 http://thread.gmane.org/gmane.comp.version-control.git/160319

If someone wants to pick any of these up and run with it, I wouldn't
mind (hey, I'd be happy).

Thanks for a useful example.
Jonathan

Re: Undo last commit?

[Jakub Narebski]

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

Re: Undo last commit?

[Massimo Manca]

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

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'.
>  


[-- Attachment #2: massimo_manca.vcf --]
[-- Type: text/x-vcard, Size: 353 bytes --]

begin:vcard
fn:Massimo Manca
n:Manca;Massimo
org:Micron Engineering di Massimo Manca
adr:;;via della Ferriera, 48;Pordenone;PN;33170;ITALIA
email;internet:massimo.manca@micronengineering.it
tel;work:+39 0434 1856131
tel;fax:+39 0434 1851032 / 178 273 3543
tel;cell:+39 349 4504979
url:http://www.micronengineering.it
version:2.1
end:vcard

Re: Undo last commit?

[Holger Hellmuth]

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'.
>>
>

Re: Undo last commit?

[Mike]

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@ira.uka.de> 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@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'.
>>>
>>
>
>

Re: Undo last commit?

[Ramkumar Ramachandra]

Hi Mike,

Mike writes:
> 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 :)

I completely agree with you.  Git's user interface can certainly be
improved -- we have had many many discussions on this topic (like
{1]).  Unfortunately, the way to go about doing it is not to implement
every little suggestion and introduce more inconsistencies;  Git is
very complex, and changing one little thing requires us to think about
how it'll affect everything else.  Yes, it does seem like a daunting
task, but the interface IS improving slowly and steadily.  You can
help by thinking about how a certain new feature will interact with
every component of Git, and participating in UI discussions.

-- Ram

[1]: http://thread.gmane.org/gmane.comp.version-control.git/175061

Re: Undo last commit?

[Junio C Hamano]

Mike <xandrani@gmail.com> writes:

> "git reset --soft HEAD^" can't be picked up that quickly by a
> beginner, but git uncommit would be obvious!

So would "git commit --amend", before which "reset --soft HEAD^" was the
only way to prepare doing it, but after which "reset --soft HEAD^" more or
less outlived its usefulness for that particular use case.

Re: Undo last commit?

[Jonathan Nieder]

Ramkumar Ramachandra wrote:
> Mike writes:

>> 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.
[...]
> Git is
> very complex, and changing one little thing requires us to think about
> how it'll affect everything else.

Oh, dear.  No, I don't think these things are true at all (or at least I
hope we act so as to make them not true).  In its history, just like Jakub
likes to remind us now and then, git _evolved_.  To make it better, it
should be sufficient to do three things:

 1. When there is a small, obvious change that can make something
    better, do it.

 2. When there is a small, obvious change that can make git simpler
    and more flexible (so other changes can become small and obvious),
    do it.

 3. When there is a big, possibly advantageous change, try it out
    locally (e.g., on a branch).  If it turns out to work well, use it.

While it is always nice to see people thinking carefully, none of the
above necessarily requires thinking about all of git at once.  In
particular, (2) suggests that any feature leading a well informed
person to say "Git is very complex" is a bug.

Re: Undo last commit?

[Mike]

You have a great attitude to design (especially that of software).

I love it when people take feedback as a positive thing, and not as a
criticism! :)

2011/6/30 Jonathan Nieder <jrnieder@gmail.com>:
> Ramkumar Ramachandra wrote:
>> Mike writes:
>
>>> 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.
> [...]
>> Git is
>> very complex, and changing one little thing requires us to think about
>> how it'll affect everything else.
>
> Oh, dear.  No, I don't think these things are true at all (or at least I
> hope we act so as to make them not true).  In its history, just like Jakub
> likes to remind us now and then, git _evolved_.  To make it better, it
> should be sufficient to do three things:
>
>  1. When there is a small, obvious change that can make something
>    better, do it.
>
>  2. When there is a small, obvious change that can make git simpler
>    and more flexible (so other changes can become small and obvious),
>    do it.
>
>  3. When there is a big, possibly advantageous change, try it out
>    locally (e.g., on a branch).  If it turns out to work well, use it.
>
> While it is always nice to see people thinking carefully, none of the
> above necessarily requires thinking about all of git at once.  In
> particular, (2) suggests that any feature leading a well informed
> person to say "Git is very complex" is a bug.
>

Re: Undo last commit?

[Neal Kreitzinger]

On 6/28/2011 8:57 AM, Holger Hellmuth wrote:
>
> It would be a nice companion to the not-yet-realized "git unadd" ;-)
>
or perhaps "git unstage"...

v/r,
neal

Re: Undo last commit?

[Jakub Narebski]

Please do not top-post, and do not remove git mailing list from Cc.
Sorry for double posting; forgot to re-add git@vger.kernel.org

On Sat, 11 Feb 2012, Mike ??? wrote:
> 2012/2/11 Neal Kreitzinger <nkreitzinger@gmail.com>
> > On 6/28/2011 8:57 AM, Holger Hellmuth wrote:
> > >
> > > It would be a nice companion to the not-yet-realized "git unadd" ;-)
> >
> > or perhaps "git unstage"...
>
> If lot's of people have the same problem then it IS a design flaw. If
> something is designed well and genuinely intuitive then they just work.
> Think iPhone, iPod, some DVD players and other well designed user
> interfaces. The same goes for command line tools... the options should have
> names that don't have any ambiguity.
> 
Many of problems with git user interface have their source from the fact
that git, including its interface, was evolved rather than created using
big-design-upfront workflow.  And it _had_ to be evolved, as there was not
much of prior art (well, not good prior art) in the area of DVCS.

Besides, as they say:

  The only "intuitive" interface is the nipple. After that it's all learned.

                                                             -- Bruce Ediger

> Techie guys almost always blame the users, this is a very bad attitude. For
> example I've met so many techies that THINK they can design websites...
> err... they can't. They CAN program sure, but they CAN'T design the user
> experience properly as that is not their expertise. Just as we wouldn't
> expect a graphic designer or user interface specialist to do the coding.
> 
There is also problem in that you need to know git well to _code_ interface;
and when you know git well you don't notice no longer the problems that you
had as a newbie.

On the other hand new git users sometimes have problems distinguishing
between accidental complexity of bad UI design, and essential complexity
of a powerfull and flexible tool.

[...]

So, Mike, will you bitch or will you try to help?

-- 
Jakub Narebski
Poland

Re: Undo last commit?

[Jonathan Nieder]

Hi,

Jakub Narebski wrote:

> So, Mike, will you bitch or will you try to help?

I sent a message (not to the git list by accident, sorry) that made
the same mistake, but I think I was misdiagnosing.

I suspect Mike wanted to invite us to take a closer look at the story
in [1] and learn what can be learned from it.  (For example, may be an
error message or some documentation needs to be improved, or maybe new
enhancements like "git checkout -B master HEAD^" would have helped.)

Unfortunately the message [1] is not very focused, making it hard to
learn from.  So my advice to Mike would be to try again, and to
clearly explain what problem he was trying to solve and when git
failed him (either by a command producing a different effect than
expected or the appropriate command to carry out some action being
hard to find).

Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/175968