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

From: Andy Parkins <andyparkins@gmail.com>
Date: Apr 17, 2007, 20:46 UTC
Message-ID: <200704172146.33665.andyparkins@gmail.com>
In-Reply-To: <Pine.LNX.4.64.0704171229360.5473@woody.linux-foundation.org>

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.

Show 5 quoted lines

> 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...

Show 5 quoted lines

> 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