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 <[EMAIL PROTECTED]> 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:


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

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


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

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

if [ $headtree == $undotree ]; then
    echo There are no changes to undo.
    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

# --- SNIP ---

and here, is the redo script


. 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


# If an 'undo name' was given on the command line then try to use it.
# If not, then automatically pick the most recent undo.
case "$#" in
    undoinfo=$undodir/$(ls -tr $undodir | sed -n 's/\.undo$//p' | tail -n 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

# 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"
    git-read-tree -u -m $(cat $undoinfo.base) $(cat $undoinfo.undo) 
    git-merge-cache git-merge-one-file-script -a

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

# --- SNIP ---

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


> 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: [EMAIL PROTECTED]
 Fort Collins, CO 80525              home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to