Re: [RFC] undo and redo

On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote:

quoted

So, I've tried cloning, pulling to|from, pushing to|from and resolving
merges in a repository with undo information stored under
.git/refs/undo.  None of these operations seem to notice the existence
of this directory.  I think this is good.

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 was thinking that undo trees should not be pushed and pulled between
repositories.  For this I would use a new branch with proper commits as
Linus suggested.

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

For this, I may also use branching, as suggested.  I meant for undo/redo
to be a lighter weight alternative to allow for a faster context switch.
I am reluctant to commit what I have in my working directory unless I
have taken the time to review the changes using diff tools and cleaned
up considerably.  This is my way of being a careful developer.  Not all
developers share my style but I know many that do.  This makes
committing a heavy weight operation for me.

So, referring to your example.  If my 'boss' says that I need to switch
to working on 'Boring but urgent fix' for the next *week* or more I will
likely take the time to make the full context switch to a new branch and
work on the fix.  I may also choose to just clone my repository and use
a new working directory.  If the fix takes just a day or two I may do
the same.

Now, let's say that the 'fix' is something that I can do in an hour or
two and quickly get back to where I was.  In this context, making the
full context switch can feel very cumbersome compared to the amount of
work required to make the fix.  Now, a simple 'git undo' will ease this
switch.

Another example is if I'm working on a commit and suddenly get a
brilliant idea for some easy modification that I want to make and commit
by itself before making this commit.  I can do this easily with

        % git undo
        % carefully make easy change
        % git commit
        % git redo

Having a light-weight alternative like this could make the difference
between realizing the easy, brilliant idea and forgetting about it on
the back burner because it was just too cumbersome to make the context
switch.

The bottom line is that I don't argue against using the existing
work-flows.  I hope to add the flexibility to use various work-flows to
fit the job at hand.

[ stuff deleted ]

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

Again, these are effective.  I simply want to provide an alternative
light weight way of accomplishing this.

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.

What other potential do you see?  I sounds like you had a stream of
thought here that didn't make it in the email.  I think there are
probably many ways that it can be useful.  I'll ask some of my
colleagues here who have liked undo/redo type functionality what they
think.

I think it would be impossible to think of all of the possibilities
ahead of time.  But, if you've thought of some, please share :-)

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.

quoted

I would be glad to write up documentation and provide a patch.

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.

This all sounds reasonable.  I'm willing to do this work.

Cheers,
Carl

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -