threads / discuss / 27648

Undo last commit?

Subject: Undo last commit?

## tl;dr

16 messages between Jun 18, 2011 and Feb 11, 2012.

replies: 15people: 9as markdown or json

Mike· Jun 18, 2011, 13:15 UTC · lore
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
Ben Walton· Jun 18, 2011, 13:43 UTC · re: Mike · lore

Re: Undo last commit?

Excerpts from Mike's message of Sat Jun 18 09:15:49 -0400 2011:
Hi Mike,
Show 6 quoted lines
> 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

Ramkumar Ramachandra· Jun 18, 2011, 13:48 UTC · re: Mike · lore

Re: Undo last commit?

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
Jakub Narebski· Jun 18, 2011, 13:54 UTC · re: Mike · lore

Re: Undo last commit?

Mike <xandrani@gmail.com> writes:
Show 35 quoted lines
> 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?
Show 6 quoted lines
> 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.

Show 12 quoted lines
> 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
Jonathan Nieder· Jun 19, 2011, 00:37 UTC · re: Jakub Narebski · lore

Re: Undo last commit?

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

Jakub Narebski· Jun 19, 2011, 10:37 UTC · re: Jonathan Nieder · lore

Re: Undo last commit?

On Sun, 19 Jun 2011, Jonathan Nieder wrote:
Show 20 quoted lines
> 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').
Show 16 quoted lines
> * 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
Massimo Manca· Jun 20, 2011, 12:08 UTC · re: Jakub Narebski · lore

Re: Undo last commit?

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:
Show 49 quoted lines
> 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'.
>

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

Holger Hellmuth· Jun 28, 2011, 13:57 UTC · re: Massimo Manca · lore

Re: Undo last commit?

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:
Show 76 quoted lines
> 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'.
>>
>
Mike· Jun 28, 2011, 14:31 UTC · re: Holger Hellmuth · lore

Re: Undo last commit?

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:
Show 100 quoted lines
> 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'.
>>>
>>
>
>
Ramkumar Ramachandra· Jun 30, 2011, 04:50 UTC · re: Mike · lore

Re: Undo last commit?

Hi Mike,
Mike writes:
Show 15 quoted lines
> 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
Jonathan Nieder· Jun 30, 2011, 18:38 UTC · re: Ramkumar Ramachandra · lore

Re: Undo last commit?

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.

Mike· Jun 30, 2011, 19:48 UTC · re: Jonathan Nieder · lore

Re: Undo last commit?

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>:
Show 31 quoted lines
> 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.
>
Junio C Hamano· Jun 30, 2011, 17:29 UTC · re: Mike · lore

Re: Undo last commit?

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.

Jakub Narebski· Feb 11, 2012, 22:07 UTC · lore

Re: Undo last commit?

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:
Show 13 quoted lines
> 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
Show 6 quoted lines
> 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
Jonathan Nieder· Feb 11, 2012, 22:29 UTC · re: Jakub Narebski · lore

Re: Undo last commit?

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

← back to recent threads