Semantics of a workspace checkpoint

I'd like to propose these as the semantics for the checkpointing of a workspace

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

Comments?

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

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?

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

On 6/16/05, Petr Baudis <pasky@ucw.cz> wrote:

I am trying to achieve a working directory that is -identical- in every respect to the working directory at the point at which the checkpoint is made. Of course, to achieve this objective my proposal should also provide a facility to capture HEAD, and MERGE_HEAD and any other tags the user might specify. [ so modify the proposal so that the contents of .git/checkpoint/<treeid>.tgz is a tar contain the index, and any saved tags ]

The reason that a treeid alone is not sufficient is that a workspace which has unresolved merges cannot be represented by a treeid alone and there is no way to make an index contain the exact state of the working directory without destroying the stage info.

So, my proposal captures the -exact- state of the index, plus the -exact- state of the working directory [ and, with the modifications just proposed, any nominated tag ]

The reason that treeid is used is to name the checkpoint is it is a simple way and error-free way to identify the tree that needs to be restored in order to restore to the checkpoint. It could be stored in the .tgz, but there doesn't seem to be a good reason not to name it by the tree id.

This doesn't achieve the objective for the reasons specified above.

jon.