{"thread":{"id":"959","subject":"Semantics of a workspace checkpoint","startedAt":"2005-06-16T08:21:28Z","lastAt":"2005-06-16T09:00:58Z","messageCount":3,"participants":["Jon Seymour","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4987","messageId":"2cfc4032050616012146948b49@mail.gmail.com","threadId":"959","inReplyTo":null,"subject":"Semantics of a workspace checkpoint","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-16T08:21:28Z","receivedAt":"2005-06-16T08:21:28Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"I'd like to propose these as the semantics for the checkpointing of a workspace\n\nOn checkpoint, create a file called:\n\n.git/checkpoint/\n\nwhere the contents of the file are:\n exactly identical to the index file immediately prior to the\ncheckpoint being performed\n\nand the treeid is the tree that results from:\n\n git-update-cache $(git-diff-files | cut -f2)\n git-write-tree\n\nTo restore from the checkpoint, one does:\n\n /* magic to remove files that are not in the resulting tree */\n git-read-tree -m \n git-checkout-cache -u -f -a\n cp .git/checkpoints/ .git/index\n\nComments?\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"4988","messageId":"20050616082847.GA10116@pasky.ji.cz","threadId":"959","inReplyTo":"2cfc4032050616012146948b49@mail.gmail.com","subject":"Re: Semantics of a workspace checkpoint","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-16T08:28:48Z","receivedAt":"2005-06-16T08:28:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Jun 16, 2005 at 10:21:28AM CEST, I got a letter\nwhere Jon Seymour told me that...\n> I'd like to propose these as the semantics for the checkpointing of a workspace\n\nWhat are you actually trying to achieve? How would you define a\ncheckpoint? Why are checkpoints good? Why don't you just commit?\nWhy do you name checkpoints by treeids?\n\n> On checkpoint, create a file called:\n> \n> .git/checkpoint/\n> \n> where the contents of the file are:\n> exactly identical to the index file immediately prior to the\n> checkpoint being performed\n> \n> and the treeid is the tree that results from:\n> \n> git-update-cache $(git-diff-files | cut -f2)\n> git-write-tree\n> \n> To restore from the checkpoint, one does:\n> \n> /* magic to remove files that are not in the resulting tree */\n> git-read-tree -m \n> git-checkout-cache -u -f -a\n> cp .git/checkpoints/ .git/index\n\nWhy do you actually store the index itself? If you did write-tree, can't\nyou just work with that alone? You essentially rebuilt the index by\ngit-read-tree -m , didn't you? (And half-destroyed it by the cp\nsince you trashed the stat information.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"4989","messageId":"2cfc403205061602004a713808@mail.gmail.com","threadId":"959","inReplyTo":"20050616082847.GA10116@pasky.ji.cz","subject":"Re: Semantics of a workspace checkpoint","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-16T09:00:58Z","receivedAt":"2005-06-16T09:00:58Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 6/16/05, Petr Baudis wrote:\n> Dear diary, on Thu, Jun 16, 2005 at 10:21:28AM CEST, I got a letter\n> where Jon Seymour told me that...\n> > I'd like to propose these as the semantics for the checkpointing of a workspace\n> \n> What are you actually trying to achieve? How would you define a\n> checkpoint? Why are checkpoints good? Why don't you just commit?\n> Why do you name checkpoints by treeids?\n\nI am trying to achieve a working directory that is -identical- in\nevery respect to the working directory at the point at which the\ncheckpoint is made. Of course, to achieve this objective my proposal\nshould also provide a facility to capture HEAD, and MERGE_HEAD and any\nother tags the user might specify. [ so modify the proposal so that\nthe contents of .git/checkpoint/.tgz is a tar contain the\nindex, and any saved tags ]\n\nThe reason that a treeid alone is not sufficient is that a workspace\nwhich has unresolved merges cannot be represented by a treeid alone\nand there is no way to make an index contain the exact state of the\nworking directory without destroying the stage info.\n\nSo, my proposal captures the -exact- state of the index, plus the\n-exact- state of the working directory [ and, with the modifications\njust proposed, any nominated tag ]\n\nThe reason that treeid is used is to name the checkpoint is it is a\nsimple way and error-free way to identify the tree that needs to be\nrestored in order to restore to the checkpoint. It could be stored in\nthe .tgz, but there doesn't seem to be a good reason not to name it by\nthe tree id.\n\n> \n> > On checkpoint, create a file called:\n> >\n> > .git/checkpoint/\n> >\n> > where the contents of the file are:\n> > exactly identical to the index file immediately prior to the\n> > checkpoint being performed\n> >\n> > and the treeid is the tree that results from:\n> >\n> > git-update-cache $(git-diff-files | cut -f2)\n> > git-write-tree\n> >\n> > To restore from the checkpoint, one does:\n> >\n> > /* magic to remove files that are not in the resulting tree */\n> > git-read-tree -m \n> > git-checkout-cache -u -f -a\n> > cp .git/checkpoints/ .git/index\n> \n> Why do you actually store the index itself? If you did write-tree, can't\n> you just work with that alone? You essentially rebuilt the index by\n> git-read-tree -m , didn't you? (And half-destroyed it by the cp\n> since you trashed the stat information.)\n> \n\nThis doesn't achieve the objective for the reasons specified above.\n\njon.\n"}]}