[01:29:55] --- dev-zero@jabber.org has become available [02:52:27] --- dev-zero@jabber.org has left [04:14:08] --- dev-zero@jabber.org has become available [05:31:27] --- Simon Wilkinson has left [05:32:22] --- Jeffrey Altman has left: Replaced by new connection [05:53:31] Not broken any more [05:55:42] I forgot its CellServDB needed to be updated, since meredtih's address changed, alycia has no dbservers, and it didn't previously know about dedlock [05:58:46] --- Simon Wilkinson has become available [05:59:08] my web server had a similar problem [05:59:33] It might interest people to know that we have modified 71% of the lines in OpenAFS [06:02:30] the people it would interest clearly like trivia. on a related note, i own nearly every variant of trivial pursuit. [06:03:08] Will, for the trivial amongst you ... [06:03:10] Total lines: 1736368 550786 31.72% Jeffrey Altman 495651 28.55% IBM 272915 15.72% Derrick Brashear 84565 4.87% Chas Williams 47227 2.72% Russ Allbery [06:04:13] (that's lines by the person who last touched them) [06:06:40] If there's one thing that git seems to be very good at, it's producing trivia from the repository... [06:26:16] i really gotta wrap my head better around how squashing merge commits is supposed to work [06:26:49] I terms of the errors you get back from gerrit? [06:27:11] well, no. i have this merge commit i had to do to clean up a conflict from the parallel make fix. [06:27:21] Okay. [06:27:25] i'd like to not have it [06:27:25] Don't do a merge commit. [06:27:43] git fetch the latest tree [06:27:45] rebase the pull? [06:27:57] make a topic branch [06:28:11] git cherry-pick the SHA1 of the patch into that branch [06:28:25] git push that into refs/changes [06:29:22] (You could also use git rebase -i and squash the merge commit away) [06:29:41] the cherry-pick fails. rebase -i didn't show me my merge commit. [06:30:20] Okay, so it's a proper real collision. [06:30:28] yes which i can fix. [06:31:07] Yeh. I'd just get the patch with git show , and git apply --reject it [06:31:41] There's a possibility that the gerrit-cherry-pick command might provide a different way of doing this, but I've never played with that. [06:32:08] (see http://gerrit.googlecode.com/svn/documentation/2.0/cmd-index.html ) [06:32:09] it might. let me see if this works [06:33:33] --- haba has left [06:34:01] maybe that worked [06:34:08] --- haba has become available [06:34:12] What did you do? [06:34:28] damn, marc beat me by a minute [06:34:53] cherrypick failed. it told me after resolving i could [06:34:55] "When commiting, use the option '-c 822e735' to retain authorship and message." [06:35:02] so i resolved, did so, and pushed [06:35:26] and then noticed marc beat me. [06:36:21] --- Jeffrey Altman has become available [06:37:03] Well gitweb thinks yours is good too. Do you want to stick what you did in the GitGatekeepers wiki page? [06:37:40] his doesn't match mine. before i do, i'd like to see if that's intentional. [06:37:54] e.g. did i break something. if not, then i will document it. [06:41:50] Your merge of line 52 of budb/Makefile.in is wrong, I think. [06:42:28] Actually, tell a lie. _His_ merge of that line is wrong. [06:43:41] That's the only difference between the two patchsets, as far as Gerrit can see. [06:44:44] Patch set 4 is the correct merge. [06:44:57] i'll let him confirm, but that's my belief also [06:45:35] I'm quite enjoying the fact that I can commit from the train, too. [06:47:59] i always could :) [06:53:13] various places tell you to pull or push from e.g. ssh://gerrit.openafs.org/openafs.git; should it not be just openafs, without .git? [06:53:35] No, gerrit knows the repository as openafs.git [06:53:41] Does it work if you just use 'openafs' ? [06:53:46] seemingly [06:54:12] Hmmm. Interesting. That's definitely not documented any where, so I wouldn't rely upon it continuing to work ... [06:54:48] aaaaaaaaaaa! [06:55:07] Is that a good noise, or a bad one ... [06:55:19] i pushed a revised patch, and it failed to cherry-pick [06:55:45] You fetched before revising, right? [06:56:09] my command history says yes [06:56:36] oh, i screwed myself by taking the irix patch [06:56:41] except an auto-merge works [06:57:11] When we're in cherry-pick mode, gerrit just rejects if a file in the patch has been modified since the patch has. [06:57:27] ok, so we're back in merge-commit hell. let's see if i can rebase it away [06:57:36] (Shawn says that's for safety - so that any merge errors, even from an auto merge, are detected) [06:57:47] would you expect that rebase -i HEAD~3 would get it? [06:58:06] Yes. [06:58:11] --- abo has left [06:58:15] Is it not showing the merge commit in that list? [06:58:36] nope [06:59:46] Hmmm. Just cherry pick it into a clean branch, and be done with it then, I think. [07:00:09] --- mdionne has become available [07:00:11] --- abo has become available [07:00:40] having fun yet? :) [07:01:26] well, learning this stuff is important [07:01:31] but fun is not a word i'd use [07:02:03] yes, it's an interesting case. got to practice rebase, resolving merge conflict, etc. [07:02:25] Do you have the download link for patch 4 still, Derrick? [07:02:36] (gerrit doesn't seem to want to tell me) [07:02:38] er, no? [07:02:48] i just cherry-picked 6e703b0a57bf830f70848b0fdeeb7ab2a70234a7 [07:02:53] Ah. Not logged in. [07:03:02] And that gave you a merge commit? [07:03:16] (refs/changes/03/3/4) [07:03:37] Merge commit 'refs/changes/03/3/4' of ssh://shadow@gerrit.openafs.org:29418/ [07:04:02] From the cherry-pick? Or from something you did earlier? [07:04:11] --- abo has left [07:05:04] the timestamp was 9:59. hm. hang on [07:05:50] no, something earlier. fixed that. now, having cherry-picked, i wonder how i push this back [07:06:13] oh, with the new commit hash [07:06:24] --- haba has left [07:06:24] Yeh, or just git push HEAD:refs/changes/ [07:06:50] --- haba has become available [07:07:16] --- abo has become available [07:07:22] there. [07:07:24] done. [07:07:44] so at this point as far as i can tell we should build on irix and hpux again [07:07:53] Excellent. [07:07:58] it looks like gerrit-cherry-pick always gives you path set 1 [07:08:21] did you mean patch set 1? [07:08:34] Okay. git rebase will get rid of merge commits. [07:09:05] I had a tree which was O->P->M (Original, marc's Patch, Merge) [07:09:09] ok. I can do: gerrit-cherry-pick 3/5 [07:09:15] git rebase -i HEAD~1 [07:09:21] gave me O->P [07:12:02] weird. wonder why it didn't for me [07:13:04] --- dev-zero@jabber.org has left [07:17:44] the openafs.org web site has been updated. cvs references gone, git references added [07:17:50] yay. [07:18:00] Excellent. Thank you! [07:18:16] thank Russ. I just finished the work he started last night. [07:18:19] I guess, at some point, we should consider whether the OpenAFS site is moved to being git hosted, too. [07:18:35] we could actually use gerrit to allow submissions to it [07:18:49] Indeed. That's what I was thinking. [07:18:53] though non-technical contributors wouldn't want to cope i suspect [07:18:58] And just serve from an automatic checkout. [07:20:10] I want to play with Confluence a bit as it is free for OpenAFS http://www.atlassian.com/software/confluence/ [07:20:37] Confluence is nice. It's what Edinburgh University are using for their University wide Wiki service. [07:20:47] However, it's not free software. [07:20:53] it is for open source projects [07:21:07] It may be free as in beer, but that's not what I meant. [07:21:39] It also doesn't let us store our data in AFS, which I thought was one of the aims. [07:21:45] their instructions are install it, set it up, make it public, tell us you are using it, and we will give you a license [07:23:04] one conclusion we came to is that any system can be exported to static content that can be stored in AFS for replication [07:27:33] --- Simon Wilkinson has left [07:31:28] should the front page have at least a brief mention of git? [07:32:10] Simon's announcement should be added to the news [07:33:13] I'm taking care of it [07:34:28] or I would if I was permitted to edit main.html. [07:34:52] once again owned by shadow giving htdocs read only [07:35:13] hahahaha [07:35:14] fixed [07:44:17] btw, I think we all owe Simon a really nice bottle of scotch [07:45:49] git news item added. time to go out and enjoy this fabulous weather [07:45:51] he can get better scotch than we can [07:46:00] tequila? [07:46:15] go enjoy. supposed to rain here, so we called of kayaking, and no rain yet. it's overcast. [07:46:36] i should, though, make breakfast. perhaps after i get a few more builds running [08:56:16] --- dev-zero@jabber.org has become available [09:08:40] --- Russ has become available [09:10:31] * Russ thinks hosting the web site in Git is a great idea. [09:10:43] * Russ also wants to set up ikiwiki for the wiki and see how that goes. [09:11:17] --- abo has left [09:11:24] Moving everything onto a similar set of tools seems like a win to me. [09:11:45] --- abo has become available [09:15:16] BTW, Jive seems way nicer than Confluence, but I don't think it's even free as in beer. [10:57:26] --- dev-zero@jabber.org has left [11:58:33] --- deason has become available [12:44:48] --- cclausen has become available [15:12:43] starking a bit... It's been my desire for some time to move what's left of the static parts of www.openafs.org into AFS and serve it from michigan, like docs is. I've held off on it because people keep telling me how someone is working on a new web site or there's going to be some CMS or.... So if someone wants to do a cvs->git converstion of that and start doing automatic checkouts, or come up with some other way to generate the directory tree containing the content, I'm all for it. I'll even be happy to arrange to start publishing it as sb.openafs.org so you can see what it's going to end up looking like. [15:14:57] I'm happy to do a CVS to Git conversion if it's helpful and makes things easier for people. It would make it easier for me certainly, since right now I have to search through my notes to remember how to publish pages. [15:15:16] I don't know how hard it is to plug another Git repository into Gerrit, but I suspect not hard. [15:15:37] comment and run 'export_htdocs openafs' is hard to remember? [15:15:43] s/comment/commit/ [15:15:54] With the docs, I assume that the CVS to Git conversion would just be using git-cvs, since there aren't the delta issues and whatnot. [15:16:32] Well, I don't have a checkout of it and don't remember where the CVS repository is, so usually it starts with me poking around on grand trying to remember where everything is and where the checked-out tree is that I could commit to, although that's mostly because I'm not really doing it properly. [15:20:07] No, you're actually supposed to use the sandbox in /data/htdocs-sb on grand, because it's set up so you can look at oldsb.openafs.org to see what it will look like before you publish. But nothign says you have to; a local sandbox would work as well. [15:20:19] (except you have to run export_htdocs on grand, naturally) [15:20:38] yes, git-cvs is probably sufficient; it's not a complicated module [15:21:35] Though you should not that export_htdocs does some postprocessing, like generating the frameless versions of the tree, and that the web server config does more postprocessing, like wrapping everything in frames [15:21:52] Russ, do you have a grand.central.org kerberos principal? [15:22:05] Or, I suppose, one in a realm that crosses with that? [15:25:54] because if you do, I really should add you to openafs:gatekeepers [15:27:03] I do have a grand kerberos principal, I'm fairly sure. [15:27:07] Let me double-check. [15:27:14] I never use it. [15:28:08] I do. [15:28:42] I even seem to be able to get tokens with it. [15:29:11] Once I unconfuse aklog about what realm to use. [15:29:34] uh, what is it? [15:30:01] rra, I think. [15:30:23] At least I can kinit as rra@GRAND.CENTRAL.ORG [15:30:39] Oh, it just doesn't exist in pts [15:30:51] Oh, that would explain why I don't have an ID in my tokens. [15:30:54] do you have a preferred pts ID? [15:31:08] BTW, I wouldn't type that password (or any password) on grand [15:31:13] Generally rra. [15:31:18] Right, I don't type passwords on grand. [15:31:31] no, I mean numeric [15:31:36] Oh! [15:31:37] people who type passwords on grand are insane [15:31:43] 11857 [15:31:51] --- haba has left [15:32:00] Not that it really matters, but that's my Stanford PTS ID, so it makes ls -l nice. [15:32:18] --- haba has become available [15:32:27] --- deason has left [15:32:43] --- stevenjenkins has left [15:32:46] --- abo has left [15:33:10] fine. rra now exists. ... and is a member of openafs:gatekeepers ... which has write access to /afs/grand.central.org/www/sb.openafs.org ... which is exported as http://sb.openafs.org/ [15:33:18] Apparently that PTS ID is terrifying to many people. [15:33:22] --- abo has become available [15:33:25] Ah, thank you! [15:33:36] why is it terrifying [15:33:49] Oh, right after I said that, like five people left the chatroom. [15:34:24] what's in that tree now was a partial attempt on my part at some point in the past to come up with a version without frames. I'd appreciate if you move that into a 'Crypt' or similar subdir before scribbling there [15:34:39] At least until we decide how such a transition is to work. [15:34:59] Okay, cool. [15:35:13] BTW, remind me later to set up remctl for this cell so people can release volumes [15:35:37] When Derrick and Jeff next read here, I'll get their opinion on whether I should go ahead and migrate the existing docs CVS tree to Git now. [15:36:18] --- deason has become available [15:36:25] you mean htdocs [15:36:31] Yes, sorry. [15:36:39] Actually I meant only the openafs part of it. [15:37:07] htdocs-openafs, I should say. [15:37:26] well, yes. htdocs-gco is my problem [15:38:31] Huh. doc/protocol/rx/rxkad-2b.pod looks like something that is actually interesting. I don't think I'd ever looked at that chunk of CVS. [15:39:14] --- stevenjenkins has become available [15:39:32] is that kolya's document? if so, it's probably the only thing in that tree of interest [15:39:39] It's the only thing in the tree. [15:40:00] It appears to be your document. [15:41:07] Oh, rxkad-2b documentation. nevermind, I thought you were referring to something else. [15:42:09] well, at least that has clean parentage, which means I can change its license to something more useful, if necessary. [15:42:26] but now, I must find food. back in a while [15:42:31] On first glance, it seems like something that would be worth committing to the OpenAFS doc tree. [15:59:38] --- dev-zero@jabber.org has become available [16:28:06] --- dev-zero@jabber.org has left [16:58:56] At the very end of a parallel build, I still do get: [16:58:58] make[3]: Entering directory `/home/eagle/dvl/openafs/src/finale' make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. [17:12:27] odd, the finale target has a + in the command. what was your make target? [17:14:15] Oh, sorry, never mind. I had an outdated Makefile. [17:14:25] Running ./config.status made it all happy. [17:16:12] Ok, no problem. [17:26:24] hrm. ~20kbps is not very fast [17:28:05] Maybe cloning the openafs repository from panera was not a great idea [18:07:16] the git document does not seem to cover what I would expect to be a fairly common case, which is having multiple sandboxes on different branches, backed by the same local copy of the repository. I mean, I don't mind having a copy of the universe, but I'd rather not have a dozen copies of the universe. [18:08:21] Usually with Git you create them with git checkout -b and keep them all in the same tree. [18:08:36] In other words, you don't make copies; you make local branches, commit to them, and switch between them with git checkout. [18:08:51] jhutz: the only way I've seen to do that is to have a bunch of symlinks in .git/ [18:08:55] It took me a bit to get used to it, but now I get annoyed by having to have multiple entirely separate checkouts with other revision control systems. [18:09:04] It's really nice, and git checkout is very fast. [18:09:18] Yeah, that suggests I can't ever have uncommitted local changes if I want to look at something else, which is massively not compatible with my workflow. [18:09:18] it doesn't help me if I want to have several different builds going at once [18:09:31] you can 'git stash' [18:09:37] deason: You can have multiple separate checkouts with the same .git repository without using checkouts. I forget what it's called under the hood. [18:09:45] Er, without using symlinks. [18:09:47] It's just rare. [18:10:03] jhutz: The entire idea of an uncommitted change is pretty much verboten in the normal Git workflow. [18:10:10] You commit everything and then throw it away later if you don't want it. [18:10:31] Plus I tend to have source volumes in AFS which are some specific version that I have built and released, and it's massively not OK to have to completely change the contents of one of those to build something else [18:10:34] git commit --amend, git reset, and git rebase --interactive makes that work fairly well. [18:11:00] Russ: really? everything I've searched for has pointed at a script called 'git-new-workdir', which makes a bunch of symlinks [18:11:46] When I'm editing source, I write constantly. I don't commit constantly. I certainly don't want to write, commit, and switch branches so that I can change what's in the other window where I'm looking at another tree. [18:12:18] deason: I think they're called shallow clones. [18:12:53] Hm, but you can't push from shallow clones, so that's not it. [18:12:57] a "shallow clone" as I understood it just pulls without pulling in the entire history [18:13:05] like, you pull the last N commits or something [18:14:12] Anyway, jhutz, the resaon why it's not in the docs is because Git doesn't make it all easy to do. [18:15:54] that, that sucks [18:16:04] there's also 'git clone --shared', but I'm not entirely sure of the ramifications of using it, and the manpage has a "do not use unless you know what you're doing" warning on it [18:16:16] ah, yes, that's it. [18:16:55] Actually, you probably want git --reference rather than git --shared. [18:17:00] But that's what I was looking for. [18:17:09] Hm. Yes, but using --reference to refer to a repository that does nothing but track master may be reasonable. [18:17:14] Exactly. [18:17:32] Then you can commit locally and the master repo is just being an object store for you for the stuff that's in master. [18:17:47] You'll need to go git fetch in it from time to time, though, so everyone else picks up the changes. [18:18:00] ah, that makes sense [18:18:16] i.e. as long as you never make local changes in the reference repository, and the upstream doesn't do something annoying, that should be safe. Not so much with --shared, since the description of how that works implies that deleting things in either repo can affect the other [18:18:21] right. [18:18:53] I don't see how "everyone else" is affected at all [18:19:48] Sorry, I mean your other repos. [18:20:03] Anyway, I will probably end up doing that on my laptop; I'm on slow network often enough not to want to fetch multiple copies of things over it [18:20:07] You want to keep fetching new objects into the master repo, or when you do a git pull in the cloned repos, they'll end up with their own copy of recent stuff. [18:20:22] Oh, yes, that's true. [18:20:25] But a simple git fetch in the master before you update the clones should be enough. [18:20:34] Since the only thing that's referenced is the object store, not the branch status. [18:20:44] So it doesn't matter what branches exist or are referenced in the master, just that the objects are present. [18:21:03] It would be nice if the object store had proper refcounting so this would not become an issue. [18:21:45] I suspect the problem is more "it would be nice if clones made with git clone --reference would update the existing refcount information in the master object store when they care". [18:22:01] Since there are refcounts (git gc uses them), but I suspect the repo clones are too detached to update them. [18:26:45] You mean s/--reference/--shared/, really. --reference is not that unsafe if you do what I describe. but it's not optimally efficient unless you always make sure you fetch in the reference repo before doing anything in any of the others. --source eliminates that problem, but allows any repo to destroy the reference [18:27:19] Ah, yes, you're right. [18:28:21] so, what exactly does that initial clone start out tracking? [18:28:48] By default, the only tracking branch set up is master, which is configured to track origin/master. [18:28:49] I think you may want clone --mirror for the referenced/shared repo, if I understand things right, which will give you a bare repo [18:29:05] * Russ thinks deason is right. [18:29:33] confusingly, the explanation for clone --mirror is not in the manpage for git-clone [18:29:41] but rather in git-remote, under 'add' [18:29:49] That avoids any local branches in your master local repository. [18:30:05] You're going to want to mess with the way push works if you do this, btw. [18:30:16] Since by default you're going to get clones configured to push to your local master instead of the remote one. [18:30:42] Oh, wait, for AFS you don't care. [18:30:43] but normally I'm pulling from git://git.openafs.org, which I don't want to push to anyway, right? [18:30:54] yeah [18:30:56] Yeah. Since we push everything explicitly to Gerrit, it doesn't matter. [18:35:11] What does --mirror give me beyond --bare? [18:35:23] Automatic retrieval of any new remote branches. [18:35:39] And all the remote branches show up as local branches rather than as remote branches, which makes it easier to clone from. [18:36:01] You get an exact copy of the repo rather than a new repo set up with the original repo as a remote. [18:36:59] Ah [18:37:44] In mirror mode, enabled with \--mirror, the refs will not be stored in the refs/remotes/ namespace, but in refs/heads/. This option only makes sense in bare repositories. If a remote uses mirror mode, furthermore, git push will always behave as if \--mirror was passed. [18:44:00] * Russ wonders why Gerrit doesn't show an owner for Adam's changes. [18:44:26] Oh, he has no name in his git identity. [19:58:37] --- mdionne has left [20:29:37] --- Russ has left: Disconnected [23:01:32] --- deason has left [23:42:56] --- cclausen has left