Re: [RFC] undo and redo

From: Carl Baldwin <cnb@fc.hp.com>
Date: Aug 25, 2005, 16:32 UTC
Message-ID: <20050825163201.GA3944@hpsvcnb.fc.hp.com>
In-Reply-To: <7v1x4izjtm.fsf@assigned-by-dhcp.cox.net>

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

Show 12 quoted lines

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

Show 18 quoted lines

> 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 ]

Show 15 quoted lines

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

Show 29 quoted lines

> 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 :-)

Show 32 quoted lines

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