On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote: > > On Wed, 17 Oct 2007, Tom Tobin wrote: > > > > Or is "unix developers" code for "my sample size of one"? > > Well, let's put it this way: that "sample" is the one that started the > project. And therefore your choices become magically reasonable? > I got to pick the license. Are you going to argue about that too? I got to > pick the way I wrote the code. Are you going to continue arguing about > that? The way you *wrote* the code is different from deciding how the code *should* be written — or is your code set in stone? (Funny, considering that we're talking about a revision control system here.) As for the license bit — yes, you certainly *did* get to pick the license. What's your point? We wouldn't even be having this discussion if it wasn't open source. > The fact is, I don't see the people arguing for spaces having actually > *done* anything for git. So why are you arguing? Oh, here you pull out the big stick: if you haven't already done anything for git, your ideas (as for what to, hmm, do for git) are worthless! Err, yeah, great perspective there. > > Interesting how you waver between "certain developers" and "me". I'm > > convinced at this point that your argument comes down to "I can't use my > > favorite text editor with all-spaces, therefore all-spaces sucks". > > Umm. And I've *told* you that. > > The whole point is: > - every single damn editor out there can handle tabs. > - it's the default > - end of story. > > What's so hard to understand? Every single damn editor out there can handle spaces. The "default" is project-by-project. Since you're BD in git-land, yes, your say-so is ultimately end-of-story. It doesn't make your argument reasonable. > > As for *disk space*? When we can measure cheap drives in sizable > > fractions of *terabytes*, this simply isn't a serious argument. > > That disk-space translates into memory usage too, and into just being > technically the *inferior* choice. > > How hard is that to accept? If you have a choice between a technically > better solution, and a technically worse one, why are you arguing for the > worse one? That disk space translates into memory usage exactly *how*? Compiled code? Or the in-memory text while you're editing? The former can't be the issue, and the latter is trivial. And, of course, this still comes up against the *benefits* of all-spaces. Benefits which have been mentioned by several people; benefits which you refuse to *acknowledge*, even if they don't sway you. > > Yeah, can you believe some projects actually *survive* with an > > all-spaces indentation rule? And ::gasp:: even *thrive*? > > Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that > *git* should not, the same way the Linux kernel does not and will not. > > Why? Because tabs are better. You (or anybody else) have simply never > given any argument against that very simple argument. You try to push an > inferior solution. Uh huh. > > Problems have been outlined, but since everything for you comes down to > > "anything that comes between me and microemacs sucks", rational > > discussion breaks down. > > Don't talk about "rational discussion", since you don't even *have* any. > > The starting point for any rational decision would be to explain why > changing tabs to spaces would actually improve anything at all. And you > have yet to show *any* such argument, while I've shown arguments to the > reverse. You're being willfully blind here. > One big one being: the person who started the project and still actually > *does* something for it actually cares. Because, once again, this makes your arguments correct, doesn't it? > In contrast, your argument seems to be "I've not actually done anything, > but I want to paint the bikeshed pink". Because, once again, being new makes one incorrect, doesn't it? You've essentially demonstrated that git's "benevolent" dictator is an asshole, and even worse, an irrational asshole. It's one thing to deal with a community member like that; when it's the BD, I think I'll move along elsewhere. Congratulations. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
