From: Petr Baudis <pasky@ucw.cz>
Date: Thu, 16 Jun 2005 08:28:48 GMT
Subject: Re: Semantics of a workspace checkpoint
Message-ID: <20050616082847.GA10116@pasky.ji.cz>
In-Reply-To: <2cfc4032050616012146948b49@mail.gmail.com>

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