On Tuesday 2007, April 17, Linus Torvalds wrote: > 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. Okay. I think this is a matter of perspective - my perspective is that if it supplies what svn/cvs supply then that would please the people who want it (of whom I am one); yours is obviously that if it isn't perfect, it's not worth doing. That's a reasonable thing to demand, and I'm not going to try and argue you out of it. > 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. If you define "work" as "works like cvs/svn does", then I was fine with it. I don't like it when my favourite VCS, that I want everyone to use, doesn't have an answer to "but does it do X?". > 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. As I said at the time, I just picked one of the two options. If you don't like that, pick the other option - collapse the keywords during the grep... > 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. Bit-for-bit as in CRLF is untouched? No? Bit-for-bit as in you said you were okay with keyword-collapsing but not expansion? You're just as willing to compromise as me, you've just drawn the line in a different place. Incidentally: for future reference, I'll read what you write regardless of whether you shout it or not. > You can try, but you are *ignoring* the things that I say. The end I've tried very hard to respond to every point you've put to me; I've not selectively chopped out bits, and I've tried to give answers that make it work as you ask. Now, none of those things were acceptable to you - which is fine - but I certinaly wasn't ignoring what you say - _disagreeing with_ is not the same as ignoring. > 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. People wanting something "wrong" so much is not a sign that they need educating, it's a sign that they need a solution. In every other respect git has a solution for them; rather than explaining to them that what they want is stupid, I'd offer that it's more appropriate to offer something better in exchange. So my keyword expansion idea is wrong - fine - where's the something better? Writing custom scripts and makefiles for every project I ever run is /not/ "something better". Anyway, it's late, and I'm tired - this has turned into a battle of wills, and I'm not that into battling. Enough antihistamine has been poured on my itch that I no longer want to scratch it. I'll send my most recent patch for the sake of history, and then abandon this project. Thanks for your time on this, I appreciate your detailed responses, even if we don't agree. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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