Semantics of a workspace checkpoint

Semantics of a workspace checkpoint

[Jon Seymour]

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?
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/

Re: Semantics of a workspace checkpoint

[Petr Baudis]

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

Re: Semantics of a workspace checkpoint

[Jon Seymour]

On 6/16/05, Petr Baudis <pasky@ucw.cz> wrote:
> 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.

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