Re: Undo last commit?

[Mike <xandrani@gmail.com>]

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