[00:13:53] --- manfred has become available [00:30:29] --- Russ has left: Disconnected [00:33:47] --- manfred has left [00:33:49] --- manfred has become available [00:43:11] --- dev-zero@jabber.org has become available [00:43:29] --- dev-zero@jabber.org has left [00:43:32] --- dev-zero@jabber.org has become available [03:59:17] --- jaltman has become available [04:18:19] --- manfred has left [04:25:01] --- jaltman has left: Disconnected [04:59:21] --- jaltman has become available [05:02:38] --- jaltman has left: Replaced by new connection [05:02:39] --- jaltman has become available [05:55:06] --- meffie has become available [05:59:12] --- jaltman has left: Replaced by new connection [05:59:13] --- jaltman has become available [05:59:28] --- Jeffrey Altman has become available [06:09:56] --- meffie has left [06:28:12] --- sxw has become available [06:29:08] Ah. This morning's message didn't make it through. Darwin kernel builds are broken by the introduction of cr_gid. I have a patch. [06:51:53] --- deason has become available [06:54:07] --- meffie has become available [07:10:50] --- manfred has become available [07:24:43] --- sxw has left [07:24:43] --- sxw has become available [07:25:25] did gerrit just derail? [07:25:46] ah, no. weird [07:25:59] oh. someone's torrenting here. sigh [07:26:46] sigh. [07:26:57] Although gerrit might have derailed, the amount I just pushed into it :) [07:27:14] there. "fixed" [07:27:20] :0 [07:43:31] Bah. Gerrit's "path conflict" detection is broken when you have a chain of patches all modifying the same file, and you're cherry picking commits. [07:45:21] I found it odd how that fails when a rebase still works without intervention [07:45:39] swx: what is your work flow for verifying patches, do you cherry-pick from refs/changes/* to a local topic branch? [07:46:54] deason: Because it's path conflict detection is purely 'has this file got a different parent SHA1 in the branch we're merging to than it does in the patch' [07:47:07] and, when we're cherry picking, it always will. [07:47:29] well, that's not a "why" [07:47:59] I suppose it's just really conservative on preventing merging two things that mess up each other? [07:48:08] That's the theory, yes. [07:49:16] meffie: I git fetch, git checkout -b verify origin/master; git pull refs/changes/; git clean; ./regen.sh -q; ./configure --enable-checking; make [07:49:29] Then git checkout origin/master; git branch -D verify [07:49:33] (to clean up) [07:50:06] If any step after the pull fails, then I mark verification as failed. That's what buildbot will do, too. [07:53:38] thanks. how is the "dependencies" set in gerrit, for example in 807. [07:54:39] It's a git branch. [07:54:56] So if you pull the tip of the branch, you'll get everything else that's on it, up until you reach a common point. [07:56:04] ok, i see. [07:57:47] There is a 'gerrit-cherry-pick' tool which you can use to get _just_ a particular change and apply it to your current branch. [08:01:51] is there a way to list the open changes from a local git repo? [08:02:31] No. [08:02:31] You can list all of the changes. [08:02:41] You can (probably) use git cherry to tell you which of those are in the tree [08:03:11] But you can't tell the difference between an abandonded change and one which is still open. [08:03:52] That's why I've been spending so much time writing a python interface to gerrit's JSON API ... [08:06:53] --- sxw has left [08:07:57] --- jaltman has left: Disconnected [08:08:58] --- sxw has become available [08:11:30] (which anyone's welcome to play with if they want) [08:12:48] hmm, I want to note something about the way we're giving all of our commits delta names.... [08:13:48] yeh? [08:13:49] from what it looks like to me, the git protocol for fetching stuff sends a list of the name of every head and the SHA1 for the tip of that head as one of the first things it does; before it determines if it even needs to send any data [08:14:14] Indeed. That's why we have repo that's got the delta names, and one that doesn't. [08:14:16] Take your pick. [08:14:20] we do? [08:14:48] Yeh. gerrit's repo doesn't have the heads, so if you use that, then you don't have the overhead. [08:15:08] I think I need to garbage collect again, though, given how long fetches are currently taking. [08:15:17] ah...okay, I've always been using git://git.openafs.org/openafs.git; we shouldn't be using that? [08:15:31] That's fine, as long as you don't mind getting all of the heads. [08:16:15] well, a 'git fetch' is can take dozens of seconds just to start to do anything for me [08:16:41] Let me see if this helps [08:16:42] I don't mind the heads on my disk, but the overhead of starting a fetch or 'git ls-remote' is pretty bad [08:16:56] and will only get worse as we add deltas to every single commit [08:17:00] You're not getting them onto your disk, though. Not unless you ask for it. [08:17:12] I mean, in theory, I wouldn't mind [08:17:16] (refs/changes/* is special - it's not pulled by default, only if you ask for it) [08:17:39] like, I don't care about the local disk space or anything; it's the network overhead that I'm annoyed by [08:19:02] Hmm. git gc is saying things I don't really like to hear. [08:19:30] the overhead I'm talking about shouldn't be affected by a 'git gc' [08:19:36] it's before any objects are sent on the wire [08:29:52] We've got so many unpacked objects that I can't pack the repo. [08:29:57] I need Russ... [08:33:28] how often do we gc, anyway? [08:33:51] We don't. [08:33:54] That's the problem. [08:34:21] In theory git will auto gc, but because this is a repo that's only every pushed into, it won't get automatically garbage collected. [08:37:07] you could have a post-update hook run 'gc --auto'; I think that would run whenever someone pushes something [08:37:38] I need to investigate, there's certainly a way of fixing this with hooks. [08:38:02] At the moment, I'm packing the repo with a 1M window size, which avoids the open files problem, at the expense of being very, very, very slow. [08:39:47] well, the other easy option is just to run it once a day/week/whatever [08:39:56] yeah, i was gonna suggest cron [08:40:28] Yeah. That was the plan originally. [08:44:15] Okay. given we have 117,460 objects in our repository, and gc has only got to 6000 in about 10 minutes, this isn't going to be done any time soon. [08:44:29] ow [08:46:27] >Indeed. That's why we have repo that's got the delta names, and one that doesn't. okay, wait, I'm confused; I'm only aware of one repo [08:46:33] do you mean accessing gerrit over ssh? [08:46:40] That's a second git repo [08:47:25] yes; the 'second repo' you're referring to is the one over ssh, port 29418? [08:47:37] Yup. [08:47:48] okay, I thought there was something else accessible via git:// [08:47:54] that makes more sense now [08:47:57] It's just a normal git repo, expect that gerrit intercepts pushes. [08:49:07] We don't have the additional heads in that repo, because it makes pushes very very slow [08:58:51] Nah. We need Russ to up the number of open files for the gerrit user. I can't do anything from here. [08:59:47] hm, the gerrit repo still has the changes/* heads, though, of course [09:00:17] Yes. We'd need a 3rd repo if we wanted to deal with that. [09:00:41] there aren't that many now, but once we start having thousands and thousands of them, that could start to make it slow again [09:00:49] Seriously, I think packing this repo will help a lot. It's what we did to fix things the last time they were running slow. It's just it never got automated. [09:01:25] I think Android will have met, and dealt, with the problem before we encounter it. [09:01:33] that's true [09:01:48] and maybe gc will do it, though it's still a nontrivial network overhead either way [09:02:27] I realize now it's only going at around 20-30Ks when I do it [09:03:06] does a "git ls-remote origin" take a long time for you, as well? [09:04:04] Everything takes a long time from this network ... [09:04:44] I'm not going to pack with Linus's bodge, because I'm worried about the other errors we're seeing, and whether they due to a too many open files problem too. So, I need the gerrit user to be able to have at least 4k open files, and I'll give it another go. [09:16:40] Sorted it in the end. Now packed. That should be a little nippier [09:19:41] --- sxw has left [09:25:38] i cry now. [09:30:51] --- dev-zero@jabber.org has left [09:50:07] --- sxw mobile has become available [09:58:23] should cherry-picks to 1.4 have a different change-id than the 1.5 change, or the same one? [09:58:38] (we currently have a few of both in 1.4) [10:02:35] --- meffie has left [10:06:25] --- jaltman has become available [10:20:43] --- sxw mobile has left [10:25:55] --- manfred has left [10:35:18] --- sxw mobile has become available [10:37:36] read the fine email I wrote when change ids went live [10:40:37] --- sxw mobile has left [10:45:30] that email also says "you _must_ remove the changeID from the cherry-picked commit message", but it seems to have worked fine without removing/changing it [10:52:31] --- jaltman has left: Disconnected [11:05:48] --- Russ has become available [11:11:46] --- sxw mobile has become available [11:16:28] if you leave the change id in place, then you run the risk that gerrit will assign your change to the same record as the previous one. [11:19:06] The email is pretty clear. Don't do it. just because it works now doesn't mean its going to keep on working, or that duplicatess with the sam id won't break us in the gtur [11:19:14] future, even. [12:42:51] * Russ is here now. Do you still need me to mess with open files? Hm, I wonder how I even do that. [12:50:27] --- meffie has become available [13:50:32] --- mdionne has become available [13:52:44] > Darwin kernel builds are broken by the introduction of cr_gid. I have a patch. Sorry - the fun of doing cross-platform changes when you only have a few to test with... [14:09:21] --- sxw mobile has left [14:59:57] --- deason has left [15:57:03] --- jaltman has become available [16:02:24] --- deason has become available [16:42:32] --- meffie has left [17:16:20] --- dev-zero@jabber.org has become available [18:24:52] --- mdionne has left [21:38:51] --- deason has left [22:07:46] --- jhutz@jis.mit.edu/owl has left: Disconnected [22:09:31] --- jhutz@jis.mit.edu/owl has become available [22:17:05] --- jhutz@jis.mit.edu/owl has left: Disconnected [23:11:16] --- Russ has left: Disconnected [23:39:34] --- dev-zero@jabber.org has left [23:47:55] --- manfred has become available