[00:49:31] --- jhutz@jis.mit.edu/owl has become available [01:24:06] --- Russ has left: Disconnected [04:20:08] --- jaltman/FrogsLeap has left: Disconnected [04:20:17] --- jaltman/FrogsLeap has become available [04:30:25] --- sxw has become available [04:33:01] --- sxw has left [11:13:19] Russ or Simon, when you see this. The OpenAFS repository needs to have an object purged from it. Andrew pushed a patchset to gerrit from Unix that adds a file whose name contains two colons. Filenames with colons in them cannot be represented on Windows. As a result it is now impossible to clone the OpenAFS git repository on a Windows system. The error message is "fatal: Could not parse object 'a61a24d1f83c6f13ccb1985d99f392496b32eebd'." [11:13:19] --- shadow@gmail.com/owlD598AE55 has left: Lost connection [11:13:19] --- ktdreyer has left: Lost connection [11:14:27] Sounds like we want a new hook prevent that in the future too. [11:14:32] yes [11:17:24] --- Russ has become available [11:21:28] Is that commit on any branch? I can't find it on master at least. [11:23:07] I don't understand how it got into the main repository. [11:26:40] I don't see any obvious way to remove this from the repository because I can't find it on any branch. I can try running git gc to remove all unreferenced commits, but failing that, I need to know what ref points to that commit or I can't really do anything. [11:26:55] its in gerrit [11:27:17] Yeah, but things in Gerrit should not be in our repository until they're pushed. [11:27:21] That's a completely separate repository. [11:27:34] builtbot works from the gerrit repo [11:27:55] Right, but what I'm saying is that this commit somehow is in the regular openafs.git repository as well. [11:29:56] if there are no references to it shouldn't a git prune remove it? [11:30:26] Ah, hm, that commit SHA1 in the main repository doesn't contain any files with double colons in the name. [11:30:33] hmm [11:30:58] Oh, I see, wrong commit. [11:31:21] fda552e990eab4b752f53fa7ecc566036a89c4ad is the problematic one. [11:32:04] Ah, apparently Gerrit pushes all its changes to the main repository even when they haven't been approved. That's probably less than ideal. [11:32:38] Well, I can remove the commit from the repository by resetting that ref and then git prune, but I don't know what that's going to do to Gerrit's database. [11:32:56] I think we need to abandon that patchset [11:33:15] That doesn't actually make it go away, and Gerrit may get confused if it ever tries to reference it. [11:33:22] Although I suppose we could live with that. [11:33:32] Is there anything in Gerrit to really expunge a change? Let me see... [11:34:42] what if the object is renamed in the repo? [11:34:59] the sha1 would be the same but the index would simply be changed [11:35:47] perhaps rename it to AFS__ukernel.pod [11:35:47] The hash includes all the file names, so that would invalidate the hash and mean that the repository wouldn't validate, which is probably going to cause us even more problems. [11:38:25] * Russ tries to figure out how to remove a ref that isn't a branch. [11:39:16] > Gerrit pushes all its changes to the main repository even when they > haven't been approved I thought that was a feature -- I've pulled patches from gerrit into my openafs.git checkout for testing, without having to add gerrit as a remote. (Adding gerrit would require supplying a ssh key, no?) [11:39:38] However, I have always needed to explicitly fetch that ref in order to have it available. [11:41:16] I'm not sure what you mean by ref that's not a branch, unless you mean that it's not in $REPO.git/refs/heads/, which shouldn't really make much difference. [11:41:38] lets just leaving everything as is for the moment. I'm going to kill off all of the builds in buildbot for items that are dependent on the bad object and see if other things can build [11:41:40] Correct. And it does; git branch -d won't do anything with it. [11:41:43] You have to use git update-ref. [11:41:49] I'm getting rid of it from the main repo now. [11:43:01] Deleting the ref and then running git prune --expire=now still doesn't get rid of it. [11:43:50] Oh, it's still in the reflog. [11:44:17] I've marked all of the patchsets that are dependent upon http://gerrit.openafs.org/#change,2049 as failed. [11:44:21] i,i "re flog" [11:45:08] (I admit, this is when I typically go in and mess with repos by hand. Using the tools provided is almost certainly a better plan though.) [11:45:09] I'm trying to avoid abandoning them. There is no good way of determining which pending builds in buildbot are associated with a given patchset in gerrit at the moment. [11:45:28] Yeah, I cleaned it out of the server references, it doesn't appear anywhere in the git repository in any other file, I ran git prune --expire=now, and that object still won't go away. [11:45:44] Presumably it's still referenced by something else. [11:45:57] ok [11:46:15] Oh, I bet the other patch set depends on it. [11:46:36] something subsequent does, yes [11:54:09] I've canceled all of the pending buildbot builds on windows builders [11:54:39] hopefully buildbot won't try to rebuild something marked "failed" [12:36:08] --- jaltman/FrogsLeap has left: Disconnected [12:48:27] --- deason has become available [14:39:36] --- jaltman/FrogsLeap has become available [15:02:31] --- deason has left [15:02:31] --- deason has become available [15:28:37] --- jaltman/FrogsLeap has left: Disconnected [16:51:09] --- sxw has become available [16:54:05] To kill that object, all of the objects which depend on it will also have to be removed. [16:54:43] And then we'll need to do some manipulation of the gerrit database so it doesn't blow it's top at the fact that objects it ref [16:55:50] ... erences are no longer in the repo. We need to make sure and get that right, or the move to a gerrit which uses git storage will be ... Interesting [16:56:27] If folk can avoid doing anything to those patches in gerrit for now, I should be able to use the dependency tree from gerrit to work out what needs tweaked. [16:59:05] --- sxw has left [17:02:01] --- sxw has become available [17:04:06] However, I think we should hold our horses here a little. This is a bug in whatever version of gut jaltman is using. Just because we can't represent a given pathname on windows shouldn't cause a clone to fail [17:07:03] Before we start repository butchering, it would be worth checking if this problem is known upstream, or even fixed in a later realise [17:19:26] --- Russ has left: Disconnected [17:25:38] --- sxw has left [20:24:45] --- jaltman/FrogsLeap has become available [22:55:41] --- deason has left [23:40:52] --- pod has left