[RFC] undo and redo

[RFC] undo and redo

[Carl Baldwin]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

Hello,

So, one thing that I liked about GNU Arch when I tried it out was the
ability to undo and redo changes in the local working copy.  I decided
to try to do this with git.  What I have is preliminary.  I'm sure it
could use some work.

So, I started with the assumption that all changes in the working copy
have been updated to the cache.  My scripts check this (with
git-diff-files) and abort if this is not the case.

Undo calls git-write-tree to write the changes to the object store.  It
stores that tree's hash and the current HEAD's tree's hash in a file.
Then it reverts the working copy to HEAD.

Redo grabs these two trees from the file, does git-write-tree to produce
a third tree and merges the three using the old HEAD's tree as the base
of the merge.  This way, new commits can happen and the local copy can
be modified since the undo and it should still work assuming no
conflicts emerge.

Attached are the two scripts.  Comments and criticism are welcome.

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

[-- Attachment #2: git-redo-script --]
[-- Type: text/plain, Size: 675 bytes --]

#!/bin/sh

. git-sh-setup-script || die "Not a git archive"

if [ -n "$(git-diff-files)" ]; then
    echo The following files should be updated!
    echo
    git-diff-files | awk '{print $6}'
fi

undostack=$GIT_DIR/undostack

if [ ! -s $undostack ]; then
    echo "No undo information in $undostack"
else
    # Read the top of the stack
    basetree=$(cat $undostack | tail -n 2 | head -n 1)
    redotree=$(cat $undostack | tail -n 1)

    # Pop the stack
    cat $undostack | head -n -2 > $undostack.tmp
    mv $undostack{.tmp,}

    currenttree=$(git-write-tree)

    git-read-tree -u -m $basetree $currenttree $redotree
    git-merge-cache git-merge-one-file-script -a
fi

[-- Attachment #3: git-undo-script --]
[-- Type: text/plain, Size: 611 bytes --]

#!/bin/sh

. git-sh-setup-script || die "Not a git archive"

if [ -n "$(git-diff-files)" ]; then
    echo The following files should be updated!
    echo
    git-diff-files | awk '{print $6}'
fi

undostack=$GIT_DIR/undostack

headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e 's/tree //')
undotree=$(git-write-tree)

if [ $headtree == $undotree ]; then
    echo There are no changes to undo.
else
    {
       echo $headtree
       echo $undotree
    } >> $undostack

    echo Saved current state as tree $undotree.
    echo Reverting to HEAD, $headtree...

    git-checkout-script -f
fi

Re: [RFC] undo and redo

[Carl Baldwin]

Oops.  I forgot to actually exit from the script if git-diff-files is
non-empty.

Also, looking at it now, I don't think keeping undo information in a
stack is the right thing.  But keeping more than just one would be good.
Oh well, my first shot is never perfect.  ;-)

Carl

On Wed, Aug 24, 2005 at 11:23:39AM -0600, Carl Baldwin wrote:
> Hello,
> 
> So, one thing that I liked about GNU Arch when I tried it out was the
> ability to undo and redo changes in the local working copy.  I decided
> to try to do this with git.  What I have is preliminary.  I'm sure it
> could use some work.
> 
> So, I started with the assumption that all changes in the working copy
> have been updated to the cache.  My scripts check this (with
> git-diff-files) and abort if this is not the case.
> 
> Undo calls git-write-tree to write the changes to the object store.  It
> stores that tree's hash and the current HEAD's tree's hash in a file.
> Then it reverts the working copy to HEAD.
> 
> Redo grabs these two trees from the file, does git-write-tree to produce
> a third tree and merges the three using the old HEAD's tree as the base
> of the merge.  This way, new commits can happen and the local copy can
> be modified since the undo and it should still work assuming no
> conflicts emerge.
> 
> Attached are the two scripts.  Comments and criticism are welcome.
> 
> 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
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> #!/bin/sh
> 
> . git-sh-setup-script || die "Not a git archive"
> 
> if [ -n "$(git-diff-files)" ]; then
>     echo The following files should be updated!
>     echo
>     git-diff-files | awk '{print $6}'
> fi
> 
> undostack=$GIT_DIR/undostack
> 
> if [ ! -s $undostack ]; then
>     echo "No undo information in $undostack"
> else
>     # Read the top of the stack
>     basetree=$(cat $undostack | tail -n 2 | head -n 1)
>     redotree=$(cat $undostack | tail -n 1)
> 
>     # Pop the stack
>     cat $undostack | head -n -2 > $undostack.tmp
>     mv $undostack{.tmp,}
> 
>     currenttree=$(git-write-tree)
> 
>     git-read-tree -u -m $basetree $currenttree $redotree
>     git-merge-cache git-merge-one-file-script -a
> fi

> #!/bin/sh
> 
> . git-sh-setup-script || die "Not a git archive"
> 
> if [ -n "$(git-diff-files)" ]; then
>     echo The following files should be updated!
>     echo
>     git-diff-files | awk '{print $6}'
> fi
> 
> undostack=$GIT_DIR/undostack
> 
> headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e 's/tree //')
> undotree=$(git-write-tree)
> 
> if [ $headtree == $undotree ]; then
>     echo There are no changes to undo.
> else
>     {
>        echo $headtree
>        echo $undotree
>     } >> $undostack
> 
>     echo Saved current state as tree $undotree.
>     echo Reverting to HEAD, $headtree...
> 
>     git-checkout-script -f
> fi


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

Re: [RFC] undo and redo

[Junio C Hamano]

Carl Baldwin <cnb@fc.hp.com> writes:

> Attached are the two scripts.  Comments and criticism are welcome.

An obligatory non-technical comment.  I would have liked to see
this not in a MIME multipart format, which made commenting on it
a bit harder than necessary.

> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename=git-undo-script
>
> #!/bin/sh
>
> . git-sh-setup-script || die "Not a git archive"
>
> if [ -n "$(git-diff-files)" ]; then
>     echo The following files should be updated!
>     echo
>     git-diff-files | awk '{print $6}'
> fi

There is nothing wrong with the above, but I would have written
it like this (I think you forgot to exit after showing the list
of files):

    git-update-cache --refresh || exit

Also nice to learn here is "git-diff-files --name-only".

> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename=git-redo-script
>
> #!/bin/sh
>
> . git-sh-setup-script || die "Not a git archive"
>
> if [ -n "$(git-diff-files)" ]; then
>     echo The following files should be updated!
>     echo
>     git-diff-files | awk '{print $6}'
> fi

Same here.

>     currenttree=$(git-write-tree)
>     git-read-tree -u -m $basetree $currenttree $redotree
>     git-merge-cache git-merge-one-file-script -a

Interesting.  Very interesting.

Re: [RFC] undo and redo

[Linus Torvalds]

On Wed, 24 Aug 2005, Carl Baldwin wrote:
>
> Oops.  I forgot to actually exit from the script if git-diff-files is
> non-empty.
> 
> Also, looking at it now, I don't think keeping undo information in a
> stack is the right thing.  But keeping more than just one would be good.
> Oh well, my first shot is never perfect.  ;-)

I would actually argue that

	git checkout -b newbranch <undo-point>

is the perfect undo.

It leaves the old state in the old branch, and creates a new branch (and
checks it out) with the state you want to revert to. The advantage is
exactly that there is no "stack" of undo's: you can have multiple
independent undo's pending, and you can continue development at any of 
them. And merge the results together.

Of course, right now we don't have a "delete branch" command, but it's 
really as simple as

	rm .git/refs/heads/branchname

(and eventually you may want to do a "git prune" to get rid of stale
objects, but that's a separate issue).

		Linus

Re: [RFC] undo and redo

[Carl Baldwin]

On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 24 Aug 2005, Carl Baldwin wrote:
> >
> > Oops.  I forgot to actually exit from the script if git-diff-files is
> > non-empty.
> > 
> > Also, looking at it now, I don't think keeping undo information in a
> > stack is the right thing.  But keeping more than just one would be good.
> > Oh well, my first shot is never perfect.  ;-)
> 
> I would actually argue that
> 
> 	git checkout -b newbranch <undo-point>
> 
> is the perfect undo.

Yes, this does the job nicely.  I've used it like this effectively.  I
meant for undo/redo to be a lighter weight way of moving (uncommitted)
changes out of the way briefly and then replaying them onto the working
directory later.

> It leaves the old state in the old branch, and creates a new branch (and
> checks it out) with the state you want to revert to. The advantage is
> exactly that there is no "stack" of undo's: you can have multiple
> independent undo's pending, and you can continue development at any of 
> them. And merge the results together.

The "stack" was the wrong thing to do.  I think I would have undo pick a
name like undo-1, undo-2 etc.  Or something like that.  redo would pick
the most recent unless told to do otherwise.

A possible advantage of undo is having the freedom to stay on the
current branch or switch to another.

> Of course, right now we don't have a "delete branch" command, but it's 
> really as simple as
>
> 	rm .git/refs/heads/branchname
> 
> (and eventually you may want to do a "git prune" to get rid of stale
> objects, but that's a separate issue).
> 
> 		Linus
> 

This brings up a good point (indirectly).  "git prune" would destroy the
undo objects.  I had thought of this but decided to ignore it for the
time being.

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

Re: [RFC] undo and redo

[Carl Baldwin]

On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
> 
> > Attached are the two scripts.  Comments and criticism are welcome.
> 
> An obligatory non-technical comment.  I would have liked to see
> this not in a MIME multipart format, which made commenting on it
> a bit harder than necessary.
> 
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: attachment; filename=git-undo-script
> >
> > #!/bin/sh
> >
> > . git-sh-setup-script || die "Not a git archive"
> >
> > if [ -n "$(git-diff-files)" ]; then
> >     echo The following files should be updated!
> >     echo
> >     git-diff-files | awk '{print $6}'
> > fi
> 
> There is nothing wrong with the above, but I would have written
> it like this (I think you forgot to exit after showing the list
> of files):
> 
>     git-update-cache --refresh || exit

I'll take this.  This is what I was going for but being new to git I
didn't know all that was available.  A good reason to request comments
:-)

> Also nice to learn here is "git-diff-files --name-only".

Also good to know, thanks.

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

Re: [RFC] undo and redo

[Daniel Barkalow]

On Wed, 24 Aug 2005, Carl Baldwin wrote:

> This brings up a good point (indirectly).  "git prune" would destroy the
> undo objects.  I had thought of this but decided to ignore it for the
> time being.

If you made undo store the tree under refs somewhere, git prune would
preserve it.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] undo and redo

[Carl Baldwin]

This is interesting.  Can a ref be to a tree rather than a commit?  And
it still works?  I guess it would.  I hadn't thought about that.

Will prune preserve any tree mentioned in any file in refs?  How does
this work exactly?

Cheers,
Carl

On Wed, Aug 24, 2005 at 04:44:48PM -0400, Daniel Barkalow wrote:
> On Wed, 24 Aug 2005, Carl Baldwin wrote:
> 
> > This brings up a good point (indirectly).  "git prune" would destroy the
> > undo objects.  I had thought of this but decided to ignore it for the
> > time being.
> 
> If you made undo store the tree under refs somewhere, git prune would
> preserve it.
> 
> 	-Daniel
> *This .sig left intentionally blank*
> 

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

Re: [RFC] undo and redo

[Daniel Barkalow]

On Wed, 24 Aug 2005, Carl Baldwin wrote:

> This is interesting.  Can a ref be to a tree rather than a commit?  And
> it still works?  I guess it would.  I hadn't thought about that.

Generally, each subdirectory of refs/ has refs to objects of the same
type, and heads/ is commits, but other directories are other things. tags/
is all tag objects, and you could have undo/ be trees.

> Will prune preserve any tree mentioned in any file in refs?  How does
> this work exactly?

It keeps any object reachable from an object that there's a ref to in
refs.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] undo and redo

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Generally, each subdirectory of refs/ has refs to objects of the same
> type, and heads/ is commits, but other directories are other things. tags/
> is all tag objects, and you could have undo/ be trees.

That's OK from the prune front, but I am not sure what the
ramifications of this for pulling, pushing, and resolving.
I would not recommend it without really thinking it through.

Also note that tags/ is not all tag objects.  I think "git tag"
by default creates a lightweight tag, not an annotated kind.

I think you could do either one of two things.  As usual, totally
untested.  Just thinking aloud.

(1) A hack.

     - Have a single "undo-redo" branch, which was forked from
       somewhere on the "master" branch.

     - When doing "undo", make a commit that has the current top
       of undo-redo branch as the first parent and the current
       HEAD commit as the second parent, using the tree that
       represents your snapshot, to grow "undo-redo" branch.

       No, this commit does *not* represent a merge, but I am
       abusing the capability to record more than one parent
       commits.

     - When running "redo", you would want a handy way to name
       what to redo.  You can say "undo-redo~N" to mean "Nth
       from the top of undo-redo branch.

       Your implementation of "redo" can either be (patch way):

       git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index

       or (merge way):

       git-read-tree -m undo-redo~N^2 undo-redo~N HEAD &&
       git-merge-cache -o git-merge-one-file-script -a

(2) Try StGIT.

Re: [RFC] undo and redo

[Carl Baldwin]

Well, both are good ideas.  Both are stack oriented, though.

I see what you mean about adding an undo directory to .git/refs/.  I
will do some tests... (read further)

On Wed, Aug 24, 2005 at 03:48:21PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Generally, each subdirectory of refs/ has refs to objects of the same
> > type, and heads/ is commits, but other directories are other things. tags/
> > is all tag objects, and you could have undo/ be trees.
> 
> That's OK from the prune front, but I am not sure what the
> ramifications of this for pulling, pushing, and resolving.
> I would not recommend it without really thinking it through.

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.

The cloned repository does not end up 'inheriting' the undo directory
(as I would expect) but does end up with any objects reachable from the
undo tree.  However, these objects get pruned on the next 'git prune'.
This, I think, is minor.

Pull seems to ignore the undo directory and, of course, the objects
reachable by the undo trees.  This is what I expected and wanted.

Resolving merges worked as expected.

I think undo trees should be considered local to the repository and this
is the behavior that I observed.  I think this is a positive.

Before reading your message, I polished up the scripts and changed them
so that they store the undo tree and the base tree's hashes in the
.git/refs/undo directory.  Also, git-redo-script can take an optional
argument...the name of the undo to replay.  I guess undo should also
take an optional argument to give the undo tree some symbolic name.

I think this is getting rather solid.  Let me know what you think.

Here is the git-undo-script:

#!/bin/sh

. git-sh-setup-script || die "Not a git archive"

git-update-cache --refresh || exit 1

undodir=$GIT_DIR/refs/undo

undoinfo=$undodir/$(date +%Y.%m.%d.%H.%M.%S)

headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | sed -n 's/^tree //p')
undotree=$(git-write-tree)

if [ $headtree == $undotree ]; then
    echo There are no changes to undo.
else
    mkdir -p $(dirname $undoinfo)
    echo $headtree > $undoinfo.base
    echo $undotree > $undoinfo.undo

    echo Saved current state in $undodir as $(basename $undoinfo)

    git-read-tree -m -u $undotree $headtree
fi

# --- SNIP ---

and here, is the redo script

#!/bin/sh

. git-sh-setup-script || die "Not a git archive"

git-update-cache --refresh || exit 1

usage () {
    echo >&2 "Usage: git-redo-script [undo name]"
    exit 1
}

undodir=$GIT_DIR/refs/undo

# If an 'undo name' was given on the command line then try to use it.
# If not, then automatically pick the most recent undo.
undoinfo=
case "$#" in
0)
    undoinfo=$undodir/$(ls -tr $undodir | sed -n 's/\.undo$//p' | tail -n 1)
    ;;
1)
    if [ -s $undodir/$1 ]; then
        undoinfo=$(echo $undodir/$1 | sed -n "s/\.[^.]*$//p")
    elif [ -s $undodir/$1.undo -a -s $undodir/$1.base ]; then
        undoinfo=$undodir/$1
    else
        usage
    fi
    ;;
*)
    usage
    ;;
esac

# Perform a three-way merge between the base tree, undo tree and current index
if [ ! -s $undoinfo.undo -o ! -s $undoinfo.base ]; then
    echo "No undo information available"
else
    git-read-tree -u -m $(cat $undoinfo.base) $(cat $undoinfo.undo) $(git-write-tree)
    git-merge-cache git-merge-one-file-script -a

    rm -f $undoinfo.*
    test -z "$(ls $undodir)" && rmdir $undodir
fi

# --- SNIP ---

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

Cheers,
Carl

> Also note that tags/ is not all tag objects.  I think "git tag"
> by default creates a lightweight tag, not an annotated kind.
> 
> I think you could do either one of two things.  As usual, totally
> untested.  Just thinking aloud.
> 
> (1) A hack.
> 
>      - Have a single "undo-redo" branch, which was forked from
>        somewhere on the "master" branch.
> 
>      - When doing "undo", make a commit that has the current top
>        of undo-redo branch as the first parent and the current
>        HEAD commit as the second parent, using the tree that
>        represents your snapshot, to grow "undo-redo" branch.
> 
>        No, this commit does *not* represent a merge, but I am
>        abusing the capability to record more than one parent
>        commits.
> 
>      - When running "redo", you would want a handy way to name
>        what to redo.  You can say "undo-redo~N" to mean "Nth
>        from the top of undo-redo branch.
> 
>        Your implementation of "redo" can either be (patch way):
> 
>        git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index
> 
>        or (merge way):
> 
>        git-read-tree -m undo-redo~N^2 undo-redo~N HEAD &&
>        git-merge-cache -o git-merge-one-file-script -a
> 
> (2) Try StGIT.
> 
> 

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

Re: [RFC] undo and redo

[Junio C Hamano]

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

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

Re: [RFC] undo and redo

[Carl Baldwin]

On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote:
> > 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.
> 
> > 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: [RFC] undo and redo

[Kalle Valo]

Carl Baldwin <cnb@fc.hp.com> writes:

> 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 have been missing the undo command since I started to use git, so
I'll share a user's perspective. 

I was also considering undo as a really lightweight command, nothing
too fancy. Usually, I want to try implement something wild or stupid,
but almost immediately decide to abandon it. With 'git undo', this
kind of prototyping would be really easy. For me, redo would be just a
backup if (read: when) I undo something important, nothing more. For
anything else I would use branches, as was suggested.

-- 
Kalle Valo

Re: [RFC] undo and redo

[Kirby C. Bohling]

On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
<snip...>
> 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.
> 
<snip...>

[Not much of a git user, but am evaluating it for possible future
usage]... 

Why not just save the changes to a file via a patch.  Just like you
would if you were sending a patch to someone else.  I have the work
flow you are talking about when I use CVS.  I just create a patch,
apply the patch in reverse (or run the command to get you a clean
working tree in the SCM).  Make my unrelated changes commit it.
Then apply the patch, possibly resolve merge conflicts,  and proceed
with finishing my original work.

Assuming your patch creation and application tools capture all the
meta-data the SCM has (which I believe git does), it's pretty simple
to simulate what you want manaully.  With only a handful of
commands.

I see the appeal of not having manually deal with the files, but
assuming you don't feel it's branch worthy, and you don't want to
have it be something someone else can access externally, it doesn't
seem like a feature I can't get almost as simply with existing git
commands.  

I guess my final question is what does undo/redo have over saving
stuff away in a patch assuming that the patch captures all of the
SCM meta-data (the add/move/remove file type commands).  If git
doesn't capture all the meta-data in a patch, it would seem better
to make it do that and get this as a side-affect.

    Thanks,
        Kirby

Re: [RFC] undo and redo

[Junio C Hamano]

"Kirby C. Bohling" <kbohling@birddog.com> writes:

> I guess my final question is what does undo/redo have over saving
> stuff away in a patch assuming that the patch captures all of the
> SCM meta-data (the add/move/remove file type commands).  If git
> doesn't capture all the meta-data in a patch, it would seem better
> to make it do that and get this as a side-affect.

One thing that Carl's undo saves that is not easily available in
the patch form is the "what is this patch based on" information.
If you had it, you could do a three-way merge instead of patch
application.

You were at A (time flows from left to right) when somebody
(maybe your bright idea) interrupted you.  You take a snapshot
of your tree state D as a pair <A, D>, and rewind the tree to
original commit A's state:

 -->A
     \
      D

Then you do the work that interrupted you, maybe making commits
B and then C:

 -->A-->B-->C
     \
      D

At this point, you would want to restart working on whatever you
were doing, which is the difference between A->D applied on top
of C.

You could keep that information as a patch between A->D and
apply it on top of C to get there, which is your approach if I
am reading you correctly.  Carl does a three-way merge between C
and D using A as the pivot point.

Re: [RFC] undo and redo

[Carl Baldwin]

On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> <snip...>
> > 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.
> > 
> <snip...>
> 
> [Not much of a git user, but am evaluating it for possible future
> usage]... 
> 
> Why not just save the changes to a file via a patch.  Just like you
> would if you were sending a patch to someone else.  I have the work
> flow you are talking about when I use CVS.  I just create a patch,
> apply the patch in reverse (or run the command to get you a clean
> working tree in the SCM).  Make my unrelated changes commit it.
> Then apply the patch, possibly resolve merge conflicts,  and proceed
> with finishing my original work.

I used to do this with CVS too.  For you and me, people who are patch
savy veterans, this is great!  However, as easy as it is I knew very few
other developers who even thought about doing it.  In the real world,
many people see a huge difference between:

git diff-cache > $patchfile
cat $patchfile | patch -R -p1
do work
cat $patchfile | patch -p1

AND

git undo
do work
git redo

The first one simply never happens with most developers.  Most don't
really think of doing something outside the tool.  The second option
will likely get used.  Plus, I know at least one person here who is very
good with patches and working outside the tool and still would love to
have the second approach available.

Is there something wrong with having flexibility?  It seems most of the
criticism of this feature is that there is already a way to accomplish
what I want to do.  Tools that can't be used flexibly are not tools that
I like to use.  Heck, I'm on UNIX aren't I?

Oops, sorry for the rant.  I'm really not in a bad mood... really.  I
hope it didn't sound like that :-).  Oh, and I didn't mean to suggest
that git is not flexible in other regards.  I think its great!  Moving
along...

> Assuming your patch creation and application tools capture all the
> meta-data the SCM has (which I believe git does), it's pretty simple
> to simulate what you want manaully.  With only a handful of
> commands.

I can simulate git manually too with just a few more commands.  Where's
the cutoff?

> I see the appeal of not having manually deal with the files, but
> assuming you don't feel it's branch worthy, and you don't want to
> have it be something someone else can access externally, it doesn't
> seem like a feature I can't get almost as simply with existing git
> commands.  

Not having to manually manage a set of patches may seem small but it
reduces a barrier that may otherwise be just high enough to hurt
productivity in certain situations.

> I guess my final question is what does undo/redo have over saving
> stuff away in a patch assuming that the patch captures all of the
> SCM meta-data (the add/move/remove file type commands).  If git
> doesn't capture all the meta-data in a patch, it would seem better
> to make it do that and get this as a side-affect.
> 
>     Thanks,
>         Kirby

Thanks for your comments.

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

Re: [RFC] undo and redo

[Kirby C. Bohling]

On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> "Kirby C. Bohling" <kbohling@birddog.com> writes:
> 
> > I guess my final question is what does undo/redo have over saving
> > stuff away in a patch assuming that the patch captures all of the
> > SCM meta-data (the add/move/remove file type commands).  If git
> > doesn't capture all the meta-data in a patch, it would seem better
> > to make it do that and get this as a side-affect.
> 
> One thing that Carl's undo saves that is not easily available in
> the patch form is the "what is this patch based on" information.
> If you had it, you could do a three-way merge instead of patch
> application.

> You were at A (time flows from left to right) when somebody
> (maybe your bright idea) interrupted you.  You take a snapshot
> of your tree state D as a pair <A, D>, and rewind the tree to
> original commit A's state:
> 
>  -->A
>      \
>       D
> 
> Then you do the work that interrupted you, maybe making commits
> B and then C:
> 
>  -->A-->B-->C
>      \
>       D
> 
> At this point, you would want to restart working on whatever you
> were doing, which is the difference between A->D applied on top
> of C.
> 
> You could keep that information as a patch between A->D and
> apply it on top of C to get there, which is your approach if I
> am reading you correctly.  Carl does a three-way merge between C
> and D using A as the pivot point.

    Just out of curiosity, why isn't the SHA1 of 'A' part of the
diff or patch format?  I mean it can't be that hard to add it as a
single line of data that git can parse to extract that piece of
information.  Then a patch would enable you to do the 3-way merge
you describe.  If added properly "regular" patch would just ignore
that line.  The patch would then record that it is relative to 'A'.

    Assuming git could be taught "git-merge-patch" and then take use
the patch that's saved during the "undo" step and has the anchor for
the patch to use as the pivot point (as described above).  Life
should be good.  There are probably corner cases I don't understand,
but it sure looks like if you have the pivot or anchor point for the
patch embedded in the patch, you have all the needed information to
pull this off.

    I would think this would be generally useful outside of the
context of "undo/redo" also.

    Kirby

Re: [RFC] undo and redo

[Kirby C. Bohling]

On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote:
> On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> > On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> > <snip...>
> > > 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.
> > > 
> > <snip...>
> > 
> > [Not much of a git user, but am evaluating it for possible future
> > usage]... 
> > 
> > Why not just save the changes to a file via a patch.  Just like you
> > would if you were sending a patch to someone else.  I have the work
> > flow you are talking about when I use CVS.  I just create a patch,
> > apply the patch in reverse (or run the command to get you a clean
> > working tree in the SCM).  Make my unrelated changes commit it.
> > Then apply the patch, possibly resolve merge conflicts,  and proceed
> > with finishing my original work.
> 
> I used to do this with CVS too.  For you and me, people who are patch
> savy veterans, this is great!  However, as easy as it is I knew very few
> other developers who even thought about doing it.  In the real world,
> many people see a huge difference between:
> 
> git diff-cache > $patchfile
> cat $patchfile | patch -R -p1
> do work
> cat $patchfile | patch -p1
> 
> AND
> 
> git undo
> do work
> git redo
> 
> The first one simply never happens with most developers.  Most don't
> really think of doing something outside the tool.  The second option
> will likely get used.  Plus, I know at least one person here who is very
> good with patches and working outside the tool and still would love to
> have the second approach available.

I guess I can see that.  I just see it as much easier to manage
multiple undo-redo states manually.  I mean, I wouldn't make anyone
use git directly if the difference between the two commands bothers
them.  git seems too low a level.  I would think one of the
procelains would be be a better level.  However, having a unified
interface for all the porcelains seems a reasonable request.

> 
> Is there something wrong with having flexibility?  It seems most of the
> criticism of this feature is that there is already a way to accomplish
> what I want to do.  Tools that can't be used flexibly are not tools that
> I like to use.  Heck, I'm on UNIX aren't I?
> 
> Oops, sorry for the rant.  I'm really not in a bad mood... really.  I
> hope it didn't sound like that :-).  Oh, and I didn't mean to suggest
> that git is not flexible in other regards.  I think its great!  Moving
> along...
> 
> > Assuming your patch creation and application tools capture all the
> > meta-data the SCM has (which I believe git does), it's pretty simple
> > to simulate what you want manaully.  With only a handful of
> > commands.
> 
> I can simulate git manually too with just a few more commands.  Where's
> the cutoff?

Yes and no.  I meant the order and style of commands was nearly
identical.  I meant applying the command line in reverse was the
only additional step.  As a workflow, I'd just document it in the
HOWTO's.  I'm a minimalist in that sense.  Sure, I use more then
echo, redirection and netcat even though in theory I could send you
this e-mail with it.  IMHO, the above undo/redo doesn't seem to save
enough effort to me.  I wouldn't bother learning undo/redo unless it
was superior to the patch way, it's just one more thing I'd have to
remember.

> 
> > I see the appeal of not having manually deal with the files, but
> > assuming you don't feel it's branch worthy, and you don't want to
> > have it be something someone else can access externally, it doesn't
> > seem like a feature I can't get almost as simply with existing git
> > commands.  
> 
> Not having to manually manage a set of patches may seem small but it
> reduces a barrier that may otherwise be just high enough to hurt
> productivity in certain situations.

I don't mean to discourge it's implementation, I really questioned
it because I figured there had to be some more subtle implications I
didn't understand about undo/redo that patch couldn't capture.  It
also seems like multiple levels of undo/redo or undo/redo on
multiple branches could get tricky for the user to track and for git
to be able to display the information to the user sanely.

    Thanks,
        Kirby

Re: [RFC] undo and redo

[Carl Baldwin]

On Thu, Aug 25, 2005 at 03:49:30PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> > "Kirby C. Bohling" <kbohling@birddog.com> writes:
>     Just out of curiosity, why isn't the SHA1 of 'A' part of the
> diff or patch format?  I mean it can't be that hard to add it as a
> single line of data that git can parse to extract that piece of
> information.  Then a patch would enable you to do the 3-way merge
> you describe.  If added properly "regular" patch would just ignore
> that line.  The patch would then record that it is relative to 'A'.

Not a bad idea.  It could be ignored in most cases and used when needed.

Carl

>     Assuming git could be taught "git-merge-patch" and then take use
> the patch that's saved during the "undo" step and has the anchor for
> the patch to use as the pivot point (as described above).  Life
> should be good.  There are probably corner cases I don't understand,
> but it sure looks like if you have the pivot or anchor point for the
> patch embedded in the patch, you have all the needed information to
> pull this off.
> 
>     I would think this would be generally useful outside of the
> context of "undo/redo" also.
> 
>     Kirby
> 
> 

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

Re: [RFC] undo and redo

[Carl Baldwin]

On Thu, Aug 25, 2005 at 04:09:29PM -0500, Kirby C. Bohling wrote:
> I guess I can see that.  I just see it as much easier to manage
> multiple undo-redo states manually.  I mean, I wouldn't make anyone
> use git directly if the difference between the two commands bothers
> them.  git seems too low a level.  I would think one of the
> procelains would be be a better level.  However, having a unified
> interface for all the porcelains seems a reasonable request.

Maybe Porcelain is the right place for it.  The question would be "Is it
important that porcelains handle undo/redo in a way that interoperates?"

> > 
> > Is there something wrong with having flexibility?  It seems most of the
> > criticism of this feature is that there is already a way to accomplish
> > what I want to do.  Tools that can't be used flexibly are not tools that
> > I like to use.  Heck, I'm on UNIX aren't I?
> > 
> > Oops, sorry for the rant.  I'm really not in a bad mood... really.  I
> > hope it didn't sound like that :-).  Oh, and I didn't mean to suggest
> > that git is not flexible in other regards.  I think its great!  Moving
> > along...
> > 
> > > Assuming your patch creation and application tools capture all the
> > > meta-data the SCM has (which I believe git does), it's pretty simple
> > > to simulate what you want manaully.  With only a handful of
> > > commands.
> > 
> > I can simulate git manually too with just a few more commands.  Where's
> > the cutoff?

This analogy *was* a bit extreme.

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