[00:38:02] --- lars.malinowsky has become available [01:15:41] --- Russ has left: Disconnected [01:50:42] --- reuteras has left [01:50:54] --- reuteras has become available [01:54:17] --- pod has become available [03:37:55] --- reuteras has left [03:41:37] --- reuteras has become available [04:34:45] --- reuteras has left [04:34:46] --- reuteras has become available [05:37:00] --- kula has become available [06:21:38] --- reuteras has left [06:23:36] --- steven.jenkins has left [06:43:20] --- steven.jenkins has become available [07:12:57] --- meffie has left [07:14:53] --- deason has become available [07:24:30] --- reuteras has become available [07:39:08] --- sxw has become available [07:40:51] --- sxw has left [07:51:59] --- jakllsch has become available [08:23:54] --- lars.malinowsky has left [08:30:33] --- reuteras has left [09:13:57] --- phalenor has left [09:14:00] --- phalenor has become available [09:15:59] --- mho has left [09:17:15] --- sxw has become available [09:42:28] --- Russ has become available [10:06:58] --- lama has become available [10:12:53] --- Russ has left: Disconnected [10:28:48] --- jaltman/FrogsLeap has left [11:03:09] --- meffie has become available [11:08:17] --- jaltman/FrogsLeap has become available [12:33:18] --- lama has left [12:43:07] --- sxw has left [13:08:36] sigh, sysname ids [13:48:54] feh, didn't expect two gerrit entries out of that [13:59:19] --- lars.malinowsky has become available [13:59:50] ugh. hate git. [14:00:03] How so? [14:00:25] (It is expected that gerrit will produce one item per new commit pushed, by the way.) [14:01:15] also the 2 items pushed should be 2 items anyway [14:05:05] oh. [14:05:36] kaduk_mitedu: can never figure out the magic spell i'm supposed to cast [14:06:09] so, how do i edit the message of ... you know what i don't even know what state my tree is in now [14:07:08] not that i'd be able to tell one state from another to begin with [14:08:43] "git commit --amend" will let you edit the message for the most recent commit [14:09:25] what about the one before that [14:10:07] to edit the one right before the most recent one, you can use git rebase -i HEAD^^ and you should be able to follow the instructions it gives for editing a specific commit [14:10:48] it says i have unstashed changes [14:11:05] you have stuff that isn't committed; "git diff" will say what it is [14:11:23] So you should commit, stash, or revert them. git status is also useful here. [14:12:14] those changes were ignored before [14:12:27] what do you mean by ignored? [14:12:37] ignored when pushing to gerrit, I imagine [14:12:48] and when i commited the changes i pushed [14:13:01] when 'git rebase'ing, the repo will go back to earlier commits temporarily, so you can't have uncommitted stuff lying around [14:13:17] you can push your committed changes while having uncommitted changes in your working copy. [14:13:31] if you don't want to get rid of it, you can git stash git rebase then 'git stash pop' when you are done [14:13:41] Did you commit everything you intended to commit for your changes? [14:13:49] asedeno: yes [14:14:02] git rebase -i HEAD~ will allow you to edit the commit messages for more than one commit [14:14:35] why should i have to stash? [14:14:39] i shouldn't. [14:15:23] i just want to edit a specific commit message, is that too much to ask? [14:15:32] Because rebase works by making a series of changes to your working directory. [14:15:49] You need a clean working copy to go and rewrite history. [14:16:10] i'm not rewriting history. i'm editing a commit message! [14:16:17] There is no such thing as editing a commit message. What rebase actually does is create a new series of commits which are very similar to the old ones. [14:16:18] That is history. [14:16:28] Yes, that's rewriting history. [14:16:28] no. it's not. [14:16:42] git must behave exactly like cvs or i can't stand it. [14:17:13] You are changing the commit message of commit A, which creates A'. You then need to rewrite B to a B' that points to A' as a parent, etc. [14:17:16] so you want it to corrupt shit silently? [14:17:43] how did you edit old commit messages in cvs? [14:18:15] cvs admin -m [14:18:35] no dependencies on anything else [14:19:01] in any case, this is how git works. there's a series of steps you can perform to do what you want. [14:19:11] but i don't like them! [14:19:16] git doesn't care. [14:19:24] i care! [14:19:40] that and a quarter will get you 25 cents. [14:19:54] unless it's a canadian quarter, in which case probably slightly more [14:20:23] ugh, this is the same reason i dropped out of advanced algebra in high school and ended my education in math [14:20:46] because canadian money's value changes? [14:20:47] To be even clearer, a commit is identified by the SHA-1 of the author and committer information, commit message, parents, and tree; changing one of those things necessarily changes the commit, which necessarily changes all commits that came after it. This is rewriting history. [14:21:08] asedeno: i don't care, git is the worst VCS ever :-) [14:21:18] Now you are just trolling and I'm going to shut up. [14:21:25] it's like, git records changes or something. changing a commit message is in and of itself a change. [14:21:33] is not. is too. is not. is too. [14:21:44] you know what, forget it. [14:22:20] next you're gonna tell me you can use a book-printing machine to print the manual for itself. [14:22:30] when you're installing it. [14:23:16] ugh. it's not like that. [14:23:35] i have a predisposition to git hating, and i'm being forced to use it. [14:24:06] > Now you are just trolling Now? I see no problem with a bit of good-natured ironic trolling. [14:27:17] Anyway, yes; like all objects in git, commits are named by a hash of their contents. The contents of a commit include, among other things, the ID of a tree describing the filesystem tree at the time of commit, the ID of a "parent" commit describing the previous state (the thing before it on the branch), and the commit message. If you change one of those things, the commit's contents change, and thus its name changes, and thus everything after it on the branch has to change (though mostly transparently to you). [14:28:13] This is called "rewriting history" (to an extent, that's a term of art; philosophical arguments don't apply), and it's to be avoided on repos that anyone else has seen, but perfectly fine on a private one. [14:30:00] Unfortunately, the way rebase actually _works_ is essentially by rolling back your working directory to the earliest thing you changed, then doing a new series of commits according to your change. This lets it do cool things like allowing you to reorder commits or combine multiple commits into one. Unfortunately, it also means you must have a clean sandbox, because otherwise your uncommitted changes would be destroyed. [14:30:53] git doesn't have very many "operate on the repository without touching my working directory" sort of operations. They're not fundamentally impossible; it just doesn't have them, and IMHO that's a valid thing to complain about. [14:31:02] [14:32:06] there could be something that just restricted you to editing commit messages, and did the equivalent of stash/rebase/'stash pop'; but yeah, doesn't exist afaik [14:32:55] I'm not sure why it would need to restrict you to editing commit messages. I see no reason why rebase could not automatically stash and pop when appropriate. [14:33:10] there's no guarantee that 'stash pop' would apply after you rebase if you change code [14:33:17] Except, of course, that it makes cleanup harder if something goes wrong partway through. [14:33:47] i really don't want to care how the damned vcs works just to get anything done. [14:34:00] <- in a completely awful mood [14:34:39] well, you asked "why", so.... [14:35:17] > would apply Uh, sure it would. stash creates a commit. commits have trees, not diffs. so popping should always work, and give you back exactly the same WD you had before. The output of 'git diff' might be very different, but, that's life. [14:36:21] $ git stash apply Auto-merging README CONFLICT (content): Merge conflict in README [14:36:53] or "pop", whatever; same result [14:37:28] 'pop'/'apply' works by just applying the diff (or git's semimagic "apply the diff with knowledge of the parents" or whatever), so it sure can fail [14:41:00] ==deason you need to know how it works only if you want to know "why..." Otherwise, well git stash git rebase -i HEAD^^ git stash pop ... assuming you want the commit before the current one If you want to modify some other commit, try XXX^ instead of HEAD^^, where XXX is the ID of the commit whose message you want to change. [14:41:25] Oh, hm; so it does. The other ought to be possible, but there appears to be no UI for that. [14:42:40] I'm not sure how; merge it? if I delete the entire tree in a rebase operation, what do I do with a stashed change that changes one line in src/foo.c ? [14:43:51] You populate the working dir with the same tree that would result from git stash branch [14:44:56] ah. I suppose, but ew; I think I'd find myself making mistakes with it that way [14:48:21] Also, git checkout stash@{0}, if you want to be explicit about what you're trying to do. [14:50:09] In any case, if the stash doesn't apply cleanly, then wholesale replacing the tree would be throwing away informaton (well, not really, because it's still in the repository, but...) [14:53:25] seems like another legit missing feature, though; I can't think of an easy way to do the equivalent (just untar a copy of the repo from the other commit, I guess) [14:54:27] or no, I suppose applying a 'git diff HEAD..stash@foo' or something would do [14:56:42] there, let's see if that made a worse mess [14:57:15] Actually, see the "Interrupted workflow" example in git-reset(1) [14:57:38] for some reason the man pages aren't installed *shrug* [14:58:02] that was intended mostly for deason [14:58:16] hrm. have a .backup volume that needs to be salvaged. vos remove doesn't work because it needs to be salvaged. bos salvage won't salvage because it's read-only, and vos backup won't do anything because the volume needs salvaging. Thoughts? [14:58:33] salvage the RW [14:58:59] already did. [14:59:24] salvage is supposed to delete it [14:59:48] Remove the .vol file for the backup. Salvage the RW again. If it doesn't come back from the dead, you're done. [15:00:42] might need to salvage twice for it to actually go away; salvaging can be dumb about that sometimes for reasons I'm not sure why yet [15:00:52] otherwise, logs should say why it's not happening [15:01:09] > reasons I'm not sure why yet because the salvager is a pile of crap [15:01:10] SalvageLog has already been rotated one too many times [15:01:30] if it's still there and not going away, a new salvage log will say why [15:01:38] --- Russ has become available [15:02:06] yeah. scanning 155GB of inodes takes forever and a half. will try anyway, though. [15:02:44] nondafs, I take it? [15:02:58] files+volumes matters more than space usage, anyway [15:03:01] yes. 1.4.something [15:03:09] jhutz: yes, but in which specific way I'm not sure [15:04:36] 1.4.14 to be exact [15:06:25] much better this time. the bk volume header was deleted by salvager. [15:06:29] It'd sure be nice if salvaging one VG didn't require scanning all the inodes on the partition [15:17:45] it doesn't on namei [15:43:13] --- deason has left [16:03:26] --- lars.malinowsky has left [17:32:17] what does setting up another build bot for another os involve? [17:37:42] See http://wiki.openafs.org/AFSLore/BuildbotSlaveHowto/ [19:41:01] --- asedeno has left [21:05:13] --- deason has become available [22:16:33] --- lars.malinowsky has become available [22:40:40] --- deason has left [23:04:45] --- reuteras has become available [23:28:42] --- reuteras has left [23:53:44] --- Russ has left: Disconnected