git undo # last command

Hi to all,

I've been using git for some time now, but I'm in no way a git expert.
I typically hack my way through the variety of commands that git
provides. I believe that most git users work similarly.

it just occurred to me -- the command that I would REALLY like to have
is simple:

  git undo

which 'undo'es the last action that has not been pushed yet --
whichever the action is. Similarly to the 'back' button in the
browser.

Currently, when I make a mistake, I have to search the net to find the
*right* command that will undo my last action/command. That's boring
and time consuming. git undo would make things much easier, I believe.

Would creating such command be possible? I guess that 'behind the
scenes', the command could analyze the reflog and act based on that.


What do you think?

-- 
Best regards,
Saša

On Fri, Aug 16, 2013 at 10:55:06AM +0200, Saša Tomić wrote:

it just occurred to me -- the command that I would REALLY like to have
is simple:

  git undo

which 'undo'es the last action that has not been pushed yet --
whichever the action is. Similarly to the 'back' button in the
browser.

One problem with such simplicity is that you need to define what an
"action" is. If I make a commit, the undo is probably "reset HEAD@{1}".
If I fetch a ref, would undo move backwards? What if I fetch multiple
refs with one command; do we undo all of them? How about during a
multiple-command operation, like a rebase? Does an undo affect the last
commit, or the whole rebase?

I think these questions can be answered (though I am not sure of the
best answer for most of them, nor even if there is a single answer that
covers all situations), but I think a starting point for any "undo"
command would be coming up with a list of what constitutes an action,
how we record the list of actions, and then an appropriate "undo"
reaction for each action.

-Peff

On Fri, Aug 16, 2013 at 3:26 PM, Jeff King [off-list ref] wrote:

On Fri, Aug 16, 2013 at 10:55:06AM +0200, Saša Tomić wrote:

quoted

it just occurred to me -- the command that I would REALLY like to have
is simple:

  git undo

which 'undo'es the last action that has not been pushed yet --
whichever the action is. Similarly to the 'back' button in the
browser.

One problem with such simplicity is that you need to define what an
"action" is. If I make a commit, the undo is probably "reset HEAD@{1}".
If I fetch a ref, would undo move backwards? What if I fetch multiple
refs with one command; do we undo all of them? How about during a
multiple-command operation, like a rebase? Does an undo affect the last
commit, or the whole rebase?

I think these questions can be answered (though I am not sure of the
best answer for most of them, nor even if there is a single answer that
covers all situations), but I think a starting point for any "undo"
command would be coming up with a list of what constitutes an action,
how we record the list of actions, and then an appropriate "undo"
reaction for each action.

-Peff

Simplicity rarely comes for free. But simplicity may not mean the same
to a new git user, and to an experienced git user or developer.

The beauty of "undo" operation/action is that there is only one
command to be learned. Whatever you do, you can "undo".
git commit ==> git reset --soft HEAD^
git add <file> ==> git reset HEAD <file>
git add <directory> ==> git rm -r --cached <directory>

However, the command that you have to do may not be easy to find in
documentation or online.

A simple workaround, that I several times employed, is to make a
backup of the repo, and to play with the repo after that. If anything
goes wrong, I restore the backup.

But git should not force me to do this. Git clearly can do more and better.

Anyway, I believe that "undo" should revert the *last* command typed
in and executed by the user, even if it's a multi-step operation such
as rebase. Of course, it would be of great help even if a user has to
run "git undo" several times for one "git rebase". You're certainly
more experienced with git under the hood, so you know which one is
easier to implement.

I would be happy to help in making a list of actions and corresponding
undo "reactions".

-- st

On Fri, Aug 16, 2013 at 04:21:59PM +0200, Saša Tomić wrote:

git commit ==> git reset --soft HEAD^

The commit does still exists, you can find it in the reflog. This is
important if you for example commits a huge file and wants to remove it.
That commit needs to be gc:ed too, and this is dangerous...

It's a not common, but often asked, question on #git@freenode . And for
many it's hard to understand why a git rm doesn't shrink their repo.

Also consider that many git commands relies on eachother. For example
the submodule scripts uses git checkout, clone, etc.
-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com