Re: Semantics of a workspace checkpoint
- From
Petr Baudis <pasky@ucw.cz>
- Date
- Jun 16, 2005, 08:28 UTC
- 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?
Show 19 quoted lines
> 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..