From: Carl Baldwin <cnb@fc.hp.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Daniel Barkalow <barkalow@iabervon.org>,
Linus Torvalds <torvalds@osdl.org>, Carl Baldwin <cnb@fc.hp.com>,
git@vger.kernel.org
Subject: Re: [RFC] undo and redo
Date: Wed, 24 Aug 2005 20:41:34 -0600 [thread overview]
Message-ID: <20050825024134.GA31886@hpsvcnb.fc.hp.com> (raw)
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:
> 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
> 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
next prev parent reply other threads:[~2005-08-25 2:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 17:23 [RFC] undo and redo Carl Baldwin
2005-08-24 18:10 ` Carl Baldwin
2005-08-24 18:51 ` Linus Torvalds
2005-08-24 19:56 ` Carl Baldwin
2005-08-24 20:44 ` Daniel Barkalow
2005-08-24 20:47 ` Carl Baldwin
2005-08-24 21:04 ` Daniel Barkalow
2005-08-24 22:48 ` Junio C Hamano
2005-08-25 2:41 ` Carl Baldwin [this message]
2005-08-25 5:06 ` Junio C Hamano
2005-08-25 16:32 ` Carl Baldwin
2005-08-25 17:39 ` Kalle Valo
2005-08-25 19:59 ` Kirby C. Bohling
2005-08-25 20:19 ` Junio C Hamano
2005-08-25 20:49 ` Kirby C. Bohling
2005-08-25 21:28 ` Carl Baldwin
2005-08-25 20:37 ` Carl Baldwin
2005-08-25 21:09 ` Kirby C. Bohling
2005-08-25 21:42 ` Carl Baldwin
2005-08-24 18:18 ` Junio C Hamano
2005-08-24 20:01 ` Carl Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050825024134.GA31886@hpsvcnb.fc.hp.com \
--to=cnb@fc.hp.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).