{"thread":{"id":"775","subject":"cg-seek messed me up","startedAt":"2005-05-31T14:33:18Z","lastAt":"2005-05-31T18:39:08Z","messageCount":4,"participants":["Zack Brown","Thomas Glanzmann","randy_dunlap","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4300","messageId":"20050531143318.GB27047@tumblerings.org","threadId":"775","inReplyTo":null,"subject":"cg-seek messed me up","fromName":"Zack Brown","fromEmail":"zbrown@tumblerings.org","sentAt":"2005-05-31T14:33:18Z","receivedAt":"2005-05-31T14:33:18Z","isPatch":false,"sender":{"key":"zbrown@tumblerings.org","avatar":null},"body":"Hi folks,\n\nI'm not positive, but I *think* I shot myself in the foot by doing a cg-seek\nwhen there were uncommitted changes in my working file set. The patching process\ncreated duplicate areas in the files, while losing other areas and giving\npatch rejects. Before I figured out the problem, I wasn't even able to seek to a\nknown state because of this, so I ended up having to recreate the files as best\nas I could from the mess I was left with in the working directory. I realize I\ncould have gotten a clean tree by cloning, but this didn't occur to me at the\ntime. It seemed like the whole repository was just corrupt.\n\nI think I recovered everything, and I know it was my own mistake, but it\nseems like this will be a common blunder by users. Maybe cg-seek should\nfirst do a comparison between the working tree and the most recent known\nstate. If the two differ, it should exit with an error.\n\nBe well,\nZack\n\n-- \nZack Brown\n"},{"id":"4303","messageId":"20050531144506.GC6706@cip.informatik.uni-erlangen.de","threadId":"775","inReplyTo":"20050531143318.GB27047@tumblerings.org","subject":"Re: cg-seek messed me up","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-31T14:45:07Z","receivedAt":"2005-05-31T14:45:07Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\nthis is exactly why I don't use it at the moment. My own frontend does\nbefore every pull/push/merge/commit a 'look for dirty files and look for\nuncommited deltas'.\n\n\tThomas\n"},{"id":"4305","messageId":"20050531082321.44d00bb5.rdunlap@xenotime.net","threadId":"775","inReplyTo":"20050531144506.GC6706@cip.informatik.uni-erlangen.de","subject":"Re: cg-seek messed me up","fromName":"randy_dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2005-05-31T15:23:21Z","receivedAt":"2005-05-31T15:23:21Z","isPatch":false,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Tue, 31 May 2005 16:45:07 +0200 Thomas Glanzmann wrote:\n\n| Hello,\n| this is exactly why I don't use it at the moment. My own frontend does\n| before every pull/push/merge/commit a 'look for dirty files and look for\n| uncommited deltas'.\n\nI don't recall where your frontend is.\nCan you (re)post a pointer to it?\n\nThanks,\n---\n~Randy\n"},{"id":"4313","messageId":"20050531183907.GE7013@pasky.ji.cz","threadId":"775","inReplyTo":"20050531143318.GB27047@tumblerings.org","subject":"Re: cg-seek messed me up","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-31T18:39:08Z","receivedAt":"2005-05-31T18:39:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, May 31, 2005 at 04:33:18PM CEST, I got a letter\nwhere Zack Brown <zbrown@tumblerings.org> told me that...\n> Hi folks,\n\nHi,\n\n> I'm not positive, but I *think* I shot myself in the foot by doing a cg-seek\n> when there were uncommitted changes in my working file set. The patching process\n> created duplicate areas in the files, while losing other areas and giving\n> patch rejects. Before I figured out the problem, I wasn't even able to seek to a\n> known state because of this, so I ended up having to recreate the files as best\n> as I could from the mess I was left with in the working directory. I realize I\n> could have gotten a clean tree by cloning, but this didn't occur to me at the\n> time. It seemed like the whole repository was just corrupt.\n> \n> I think I recovered everything, and I know it was my own mistake, but it\n> seems like this will be a common blunder by users. Maybe cg-seek should\n> first do a comparison between the working tree and the most recent known\n> state. If the two differ, it should exit with an error.\n\nI've rewritten cg-seek to use the magical tree_timewarp function. So\nwhat it will do now is that it will save the local changes, then just\noverwrite the tree with the seeked-to target and then it will reapply\nthe local changes. This should give much better (although still far from\nperfect) results and reduce the inconsistencies popping up.\n\nAnyway, anytime you are in trouble, cg-cancel is the way out! ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"}]}