Re: [PATCH 2/2] Add keyword unexpansion support to convert.c

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@gmail.com