Re: Semantics of a workspace checkpoint

[Petr Baudis <pasky@ucw.cz>]

Dear diary, on Thu, Jun 16, 2005 at 10:21:28AM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> I'd like to propose these as the semantics for the checkpointing of a workspace

What are you actually trying to achieve? How would you define a
checkpoint? Why are checkpoints good? Why don't you just commit?
Why do you name checkpoints by treeids?

> On checkpoint, create a file called:
> 
> .git/checkpoint/<treeid>
> 
> where the contents of the file are:
>     exactly identical to the index file immediately prior to the
> checkpoint being performed
> 
> and the treeid is the tree that results from:
> 
>     git-update-cache $(git-diff-files | cut -f2)
>     git-write-tree
> 
> To restore from the checkpoint, one does:
> 
>     /* magic to remove files that are not in the resulting tree */
>     git-read-tree -m <treeid>
>     git-checkout-cache -u -f -a
>     cp .git/checkpoints/<treeid> .git/index

Why do you actually store the index itself? If you did write-tree, can't
you just work with that alone? You essentially rebuilt the index by
git-read-tree -m <treeid>, didn't you? (And half-destroyed it by the cp
since you trashed the stat information.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..