Re: Semantics of a workspace checkpoint

From: Jon Seymour <jon.seymour@gmail.com>
Date: Jun 16, 2005, 09:00 UTC
Message-ID: <2cfc403205061602004a713808@mail.gmail.com>
In-Reply-To: <20050616082847.GA10116@pasky.ji.cz>

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

Show 7 quoted lines

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

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.

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

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

jon.