Re: [RFC] undo and redo

From: Junio C Hamano <junkio@cox.net>
Date: Aug 24, 2005, 22:48 UTC
Message-ID: <7vd5o3ar4a.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0508241651420.23242@iabervon.org>

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.