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