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

[Andy Parkins <andyparkins@gmail.com>]

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