[00:13:38] --- pod has left [00:54:31] --- Simon Wilkinson has left [01:01:23] --- kaj has become available [01:18:16] --- rod has become available [02:43:48] --- Simon Wilkinson has become available [04:42:13] --- Simon Wilkinson has left [04:49:24] --- Simon Wilkinson has become available [04:55:52] --- Russ has become available [05:09:31] --- pod has become available [06:16:12] --- jaltman has left: Disconnected [07:12:58] --- jaltman has become available [07:20:11] --- dwbotsch has left [07:31:12] --- jaltman has left: Disconnected [07:31:38] --- jaltman has become available [07:35:50] --- deason-gmail has become available [07:36:53] --- RedBear has become available [09:01:34] --- kaj has left [09:13:57] --- reuteras has left [09:55:36] --- rod has left [10:50:52] --- kaj has become available [10:53:24] does 2468 just change 8 spaces into a tab? [10:54:00] I would have thought 8 spaces is sometimes preferable... I've been deliberately using them for e.g. aligning comments [10:55:11] it's just marcus' fix-rst script run with the -t option, so basically but not exactly. it tries to be smarter than just blindly doing it [10:56:00] i'm not sure i'm wild about it, to be honest. but i at least pushed it and we can argue. i think i may -1 it myself. [10:56:43] the register and trailing whitespace stuff, sure. [10:57:23] --- Kevin Sumner has left [10:58:05] --- Kevin Sumner has become available [11:06:05] > 8 spaces I had the impression that the bulk of the code was 4-space indents, but collapse to 8-space-width tabs if possible. [11:07:39] yes, but sometimes I have 8 spaces where I'm not indenting, so I say I don't want a tab there [11:08:15] but I guess it doesn't much matter; it's not like I can change the tab stop and have anything be readable anyway [11:09:24] I would prefer the use of spaces to tabs. There are simply too many different editors out there with different configurations for tab stops, etc. [11:09:48] its a huge can of worms and a thousand different preferences. we've discussed this before [11:10:11] I would be happy if we simply got rid of all of the trailing white space [11:10:34] we will. it's a different gerrit patch [11:10:39] ==jaltman on all counts so far. [11:12:42] --- Kevin Sumner has left [11:13:33] --- Kevin Sumner has become available [11:14:41] > we've discussed this before we're not discussing spaces v tabs afaict [11:24:04] looks like openafs-cvs isn't updating; last message looks to be from sunday, four days ago [11:24:35] i guess the mail server change fvkt something [11:25:07] there is a ticket in RT indicating that openafs-devel isn't working. [11:27:20] --- Russ has left: Disconnected [11:32:03] --- Kevin Sumner has left [11:32:21] --- Kevin Sumner has become available [11:48:49] thanks, whoever poked the lists :) [11:48:58] chaskiel [11:49:17] he says the mailman dislikes subject headers containing " " [12:47:42] --- jaltman has left: Disconnected [12:56:25] --- rra has become available [13:03:01] ==jaltman -- I'd really prefer spaces to tabs in the whole source base. But I don't feel strongly about us making that change and breaking the external trees. [13:17:05] --- Simon Wilkinson has left [14:47:55] --- Simon Wilkinson has become available [14:55:59] A change of spaces to tabs shouldn't be too hard for external trees to handle, because you can deal with it by telling patch, or git, to ignore whitespace changes. [14:56:24] That works less well if mixed in with content changes, though. [14:57:03] My experience is that it still deals relatively well - providing there's still a single piece of whitespace everywhere that there was whitespace. [15:00:46] Don't mix it with content changes. A reindent should always be a separate commit [15:00:53] (I'm think of patch -l and git's relatively new --ignore-whitespace option) [15:01:20] I don't think anyone is proposing mixing these changes with content changes. [15:07:12] I think the point was more that if, since your last change, there have been both content changes and whitespace changes, that may make things harder. But by and large that shouldn't be the case with Git, since Git is good at merges. [15:07:22] Since your last merge, rather. [15:08:06] And modern git is good at letting you treat whitespace changes as patch fuzz. Providing you do that, I think you should be fine. [15:08:22] I can certainly rebase on top of the whitespace changes we're discussing. [15:25:04] --- Simon Wilkinson has left [15:54:19] --- jaltman has become available [16:25:21] --- deason has become available [16:25:33] --- deason-gmail has left [16:33:02] --- deason has left [19:49:55] --- deason has become available [20:25:25] --- CUDave has become available [20:31:54] --- Born Fool has become available [21:52:43] --- Born Fool has left [23:09:53] --- Russ has become available [23:21:32] --- deason has left [23:21:40] --- reuteras has become available [23:21:41] --- kaj has left [23:58:46] --- kaj has become available