[02:15:05] --- Russ has left: Disconnected [05:27:47] --- Jeffrey Altman has left: Replaced by new connection [07:17:23] --- Jeffrey Altman has become available [08:50:36] --- cclausen has left [09:08:56] Well, I now have a git tree where all bar 2 of the tags match those in CVS. So, I think I might be almost done ... [10:47:29] --- Russ has become available [11:07:17] --- cclausen has become available [11:32:37] --- edgester has become available [11:35:16] Simon Wilkinson: cool! which branches are included? [11:40:03] All of them, bar openafs-rxkad-krb5-lha [12:16:10] excellent! [12:42:18] Unfortunately, there are 200 deltas (out of ~12500) that can't be merged into a single changeset. But I don't that that's bad going. [13:00:24] 1.6% is pretty good. [13:08:07] This only to October of last year at present, I need to grab an up to date CVS tree and test everything on that. But pretty much nothing is hardcoded, so I expect (touch wood) that it should continue to work. [13:09:46] hopefully [13:11:29] do the 200 exceptions have to be handled manually? [14:03:34] Most of them can't be handled, because they span branch or tag points. My plan is just to create split deltas, and when the git wdelta gets written, it just gets taught how to merge multiple changesets into a single delta (in much the way as it does with CVS now) [14:04:22] ok, so most things will be consistent? [14:04:37] Yes. You shouldn't notice any change from what we've got now. [14:04:44] cool [14:05:24] I'm looking forward to using git with openafs. I didn't realize why git was needed until I started doing lots of doc updates without CVS access [14:05:43] It's not going to be quite as perfect as originally conceived (for example, I'm not handling the case where a file is modified by delta A, then by delta B, then by delta A again), but I think it should be good enough. [14:06:12] huh? [14:06:24] dueling deltas? [14:06:32] In other words, it doesn't handle cases where the gatekeepers screwed up. :) [14:06:33] time travelling deltas? [14:06:41] ah, ok [14:07:00] is that because the vault files were edited? [14:07:16] Yeh. You'd do delta A, then do delta B, then realise that delta A is broken. So you'd commit a further change to fix what you broke, and call it delta A again. [14:07:31] No, vault file editing is a separate problem :) [14:07:48] ohhhhhhhhhhhhh [14:08:19] * Russ is looking forward to the mass purge of the Id and Revision strings. [14:08:21] I wish there were better git tools for windows [14:08:30] Yeah, it would be nice. [14:08:37] Russ: why [14:08:40] Russ: We need a mass addition of .gitignore files, too. [14:08:50] edgester: git doesn't really have a concept of revision numbers. [14:09:03] ah [14:09:12] Yeah, although by and large you can just rename .cvsignore to .gitignore and then clean up the duplicate stuff later. [14:09:23] I forget. Do you use an sha1 sum to refer to snapshots? [14:09:50] --- abo has left [14:09:51] * Russ is looking forward to getting rid of them because they're a complete pain in the ass for maintaining the Debian packages, where I pull up selected deltas and then have to resolve three million ^)&#$ Id conflicts. [14:10:09] --- stevenjenkins has left [14:10:20] oh, where the ID's change, but the content doesn't? [14:10:53] Where I pull up one delta that changes the Id, and then the next release has more commits for that file so also changes the Id, and then merging the next source release creates a conflict since the Id is different. [14:11:10] ouch! [14:11:17] Happens *all the time*. [14:13:27] --- stevenjenkins has become available [14:14:54] git should make cherry picking deltas much, much easier. [14:15:12] cool [14:15:51] I need to decide if delta names are going to be tags, which makes git-tags very,very,very slow (given its got 10,000 to deal with), or if I'm going to have refs/deltas, which means git tags is much faster, but you have to explicitly tell get if you're dealing with a delta. [14:21:14] what is the path of least surprise for users? [14:23:22] Well, it's all new for users. [14:23:57] I suspect that the patch of least surprise will be to not expose all of the deltas as tags - if only because of the amount of time that will make a fetch take, if you choose to fetch tags. [14:24:32] only some deltas would be tags? [14:24:55] You'd create a different set of 'refs' objects, which represent deltas. [14:25:11] And then the tags name space would just contain things that are really tags. [14:28:17] I guess no tags are ok. having some some, but not all deltas b tags would be confusing [14:28:39] I wouldn't do some, but not all, deltas. It's all or nothing. [14:29:27] good [15:20:08] --- cg2v has become available [15:22:25] --- cg2v has left [16:47:20] --- mdionne has become available [18:13:17] --- edgester has left [18:58:46] --- mdionne has left [21:23:58] --- cclausen has left [21:39:09] --- Jeffrey Altman has left [21:48:23] --- haba has become available [21:58:43] --- Jeffrey Altman has become available [22:21:11] > I suspect that the patch of least surprise [22:21:24] patch of least surprise is just funny to me [23:15:41] --- reuteras has become available [23:40:11] --- Russ has left: Disconnected