On Tue, 17 Apr 2007, Andy Parkins wrote: > > Look, my primary objection to this is the SHOUTING about how impossible > it is even though I've tried to address every problem you've thrown at > me No, you haven't. You've "addressed" them by stating they don't matter. It doesn't "matter" that a diff won't actually apply to a checked-out tree, because you fix it up in another tool. And it doesn't "matter" that switching branches will just result in the wrong keyword expansion, because you don't care about the keywords actually being "correct" - they are just random strings, and it apparently doesn't really have to "work" as far as you're concerned. And the "git grep" concern you just dismissed by stating that it should use the filesystem copy, never mind that this just means that a clean working tree gets different results from doing the same thing based on that same revision. In other words, you simply don't seem to worry about TRUSTING the results. It's ok if patches don't apply, or if you get different results on working trees than "inside" the revision control. And the reaon I'm shouting is that "it doesn't matter that it's a bit hacky" mentality is what gets you things like CVS in the end. Bit-for-bit results actually matter. Guarantees actually matter. And you should not be able to see a differece in the working tree just because you happened to be on a different branch before. Those are the kind of nasty surprises that make people go: "I don't know what the end result is, because there is an element of 'just how did you happen to do that operation' to it". I want to *trust* the SCM I use. > I'm finding it really difficult to figure out why you're trying so > hard to dissuade me from even _trying_. You can try, but you are *ignoring* the things that I say. The end result will either perform really badly, or you cannot trust it, or *both*. And you'll introduce interesting semantics like "diffs won't actually apply to the working tree with normal tools". (And yes, git diffs are extended, but they *do* apply to working trees in all cases where normal "patch" can even support the notion in the first place.) And it's not just things like diff and switching branches. If you want your keywords to generate things like "last modified by Xyzzy", you haven't even explained *how* you'd do that. Yeah, you can do git log --pretty=oneline --abbrev-commit -1 -- filename etc, and you probably think it's instantaneous, but do the timings for a big repository with a file that hasn't been modified in months, and then imagine doing that for an initial checkout (say, after you set the "keyword" attribute for all *.c files). Whoops. The checkout took an hour. Is that really a path you want to go down? > Keywords are so hated by everyone that I doubt they would ever be > accepted into git - it's an intellectual exercise for me at this stage > really. If that's what it is, fine. But people on the list seem to actually *want* it. They must be educated what a *disaster* it would be to actually try to really support something like it in real life, and not just as a mental exercise. Linus - 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