Re: [RFC] undo and redo

What I meant was that, when "undo/bar" is a tree object, things may work in a funny way:

    $ git pull ../repo-with-undo/.git refs/undo/bar

    $ git push ../other-repo/.git undo/bar:refs/heads/foo
    $ cd ../other-repo && git resolve master foo 'Attempt to merge undo'

I think this undo/redo first needs to be thought about how best it is used. My guess is that the workflow you have in mind is something like this:

    $ git checkout master
    $ hack hack hack
    # Hmph, it almost works, and but my boss says work on
    # some other feature that is more urgent
    $ git undo
    Saved current state as 2005-08-24T20:32:22
    $ work work work
    $ git commit -m 'Boring but urgent fix'
    # Ok, now let's back to the thing I wanted to do.
    $ git redo
    # I happen to know it is the last undo, so I did not name
    # it, but I could have said 2005-08-24T20:32:22
    $ hack more
    $ git commit -m 'Finally fix frotz.'

I see some problems in this.

One is minor. As you mentioned about "giving undo a symbolic name", after you accumulate a handful undo, you would need them to have descriptive names, and a way to list them before using "git redo".

But as Linus suggested in another reply, you could as well have done this without inventing these two commands.

    $ git checkout master
    $ hack hack hack
    # Hmph, it almost works, and but my boss says work on
    # some other feature that is more urgent
    $ git commit -m 'WIP - fix frotz'
    $ git branch anchor-frotz
    $ git reset --hard master^
    $ work work work
    $ git commit -m 'Boring but urgent fix'
    # Ok, now let's go back to the thing I wanted to do.
    $ git pull . anchor-frotz
    $ rm .git/heads/anchor-frotz
    $ git reset --soft master^
    $ hack more
    $ git commit -m 'Finally fix frotz.'

The above flow would be something somebody not so organized (like myself) would do. A perfect person would have done this:

    $ git checkout -b frotz master
    $ hack hack hack
    # Hmph, it almost works, and but my boss says work on
    # some other feature that is more urgent
    $ git commit -m 'WIP - fix frotz'
    $ git checkout master
    $ work work work
    $ git commit -m 'Boring but urgent fix'
    # Ok, now let's go back to the thing I wanted to do.
    $ git checkout frotz
    $ git reset --soft HEAD^
    $ hack more
    $ git commit -m 'Finally fix frotz.'
    $ git checkout master
    $ git pull . frotz
    $ rm .git/refs/heads/frotz

The "perfect person" approach has an added benefit that you could have made intermediate commits while doing "hacking", because your hackery is always done in the "frotz" branch.

Of course, the scenarios your undo/redo is useful for may not be limited to this "handling interrupt" use case. If that is the only thing it solves, then I do not see much point having them as new commands. I think the undo/redo has potential beyond that.

So let's first clarify what kind of workflow these new commands would help, how well that workflow is applicable in general, and then how well these new commands would help that workflow.

Sure. I think a set of patches for new commands, and new options to existing commands should ideally include the following:

 - Justification, such as:

   - The problems new commands/options address.
   - The expected workflow the new commands/options fit in.
   - How useful that workflow is.
   - How impossible or cumbersome to achieve that workflow using
     existing tools.

   Some of these should go to the commit log message, and the
   documentation to describe the "best practice" workflow using
   the new feature should go to Documentation/howto/ directory.

 - Documentation.  Files Documentation/git-*.txt to describe
   new commands or updates to existing pages, new entry in
   Documentation/Makefile as necessary, and a new link from
   Documentation/git.txt to reach that page.

 - Implementation.

 - Test scripts in t/ directory, either a new test script or
   updates to existing ones, if the patch is to fix existing
   implementation.