From: Junio C Hamano Date: Wed, 24 Aug 2005 22:48:21 GMT Subject: Re: [RFC] undo and redo Message-ID: <7vd5o3ar4a.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Daniel Barkalow 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.