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@xxxxxxxxx> writes:
% git reset --hard HEAD~1
Errr... here you screwed up. This reset state of you working area to
the state at last commit, removing all your changes to tracked files.
Or rather, here we screwed up. Jakub and others gave some useful
advice about how to recover, so let's consider how the UI or
documentation could be improved to prevent it from happening again.
* In this example if I understand correctly then the index contained
some useful information, perhaps about a larger commit intended for
later. To preserve that, you could have used
git reset --soft HEAD~1
which would _just_ undo the effect of "git commit", leaving the index
and worktree alone.
Another issue is that Mike haven't realized that `--amend' option can be
used *in combination* with other "git commit" options, which means that
the solution to his problem was using "git commit" as it should have
been done, but with '--amend' added.
I'm not sure if git documentation talks about 'git reset --soft HEAD^',
and when to use it; from what I remember it encourages use of
'git commit --amend' instead (which was I guess most often used reason
of using soft reset before there was '--amend').
* Another situation that comes up from time to time is making a change
that just turned out to be a bad idea. After commiting it, you might
want to discard the erroneous change, like so:
git reset --keep HEAD~1
The "--keep" option uses some safeguards to make sure that only the
committed change gets discarded, instead of clobbering local changes
at the same time.
* In the early days of git, the "--keep" option did not exist. So a lot
of old documentation recommends to do
git reset --hard HEAD~1
which is the same if you don't have any local changes.
Yes, it would be good idea to examine git documentation (tutorials,
user's manual, manpages, perhaps "Git Community Book" and "Pro Git"
too) to encourage use of new safer options of hard reset, namely
'--keep' and '--merge' instead of '--hard'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html