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
From: Ben Walton <hidden> Date: 2016-06-15 22:51:29
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:51:29
Mike [off-list ref] 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
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
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:51:29
Hi,
Jakub Narebski wrote:
Mike [off-list ref] writes:
quoted
% 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/165358http://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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:51:29
On Sun, 19 Jun 2011, Jonathan Nieder wrote:
Jakub Narebski wrote:
quoted
Mike [off-list ref] writes:
quoted
quoted
% 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
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:
quoted
Jakub Narebski wrote:
quoted
Mike [off-list ref] writes:
quoted
% 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').
quoted
* 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'.
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:
quoted
On Sun, 19 Jun 2011, Jonathan Nieder wrote:
quoted
Jakub Narebski wrote:
quoted
Mike[off-list ref] writes:
quoted
% 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').
quoted
* 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'.
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 [off-list ref] 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:
quoted
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:
quoted
On Sun, 19 Jun 2011, Jonathan Nieder wrote:
quoted
Jakub Narebski wrote:
quoted
Mike[off-list ref] writes:
quoted
% 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').
quoted
* 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'.
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
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:51:32
Ramkumar Ramachandra wrote:
Mike writes:
quoted
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.
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 [off-list ref]:
Ramkumar Ramachandra wrote:
quoted
Mike writes:
quoted
quoted
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.
[...]
quoted
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.