git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] undo and redo

From
CBCarl Baldwin <cnb@fc.hp.com>
Date
Aug 25, 2005, 02:41 UTC
Message-ID
<20050825024134.GA31886@hpsvcnb.fc.hp.com>
In-Reply-To
<7vd5o3ar4a.fsf@assigned-by-dhcp.cox.net>
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:
Show 9 quoted lines
> 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

Show 36 quoted lines
> 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 21 in “[RFC] undo and redo”
  1. Carl BaldwinAug 24, 2005
  2. Carl BaldwinAug 24, 2005
  3. Linus TorvaldsAug 24, 2005
  4. Carl BaldwinAug 24, 2005
  5. Daniel BarkalowAug 24, 2005
  6. Carl BaldwinAug 24, 2005
  7. Daniel BarkalowAug 24, 2005
  8. Junio C HamanoAug 24, 2005
  9. Carl BaldwinAug 25, 2005
  10. Junio C HamanoAug 25, 2005
  11. Carl BaldwinAug 25, 2005
  12. Kalle ValoAug 25, 2005
  13. Kirby C. BohlingAug 25, 2005
  14. Junio C HamanoAug 25, 2005
  15. Kirby C. BohlingAug 25, 2005
  16. Carl BaldwinAug 25, 2005
  17. Carl BaldwinAug 25, 2005
  18. Kirby C. BohlingAug 25, 2005
  19. Carl BaldwinAug 25, 2005
  20. Junio C HamanoAug 24, 2005
  21. Carl BaldwinAug 24, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.