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

From: David Lang <david.lang@digitalinsight.com>
Date: Apr 17, 2007, 20:05 UTC
Message-ID: <Pine.LNX.4.63.0704171302200.1696@qynat.qvtvafvgr.pbz>
In-Reply-To: <alpine.LFD.0.98.0704171624190.4504@xanadu.home>

On Tue, 17 Apr 2007, Nicolas Pitre wrote:

Show 13 quoted lines

> On Tue, 17 Apr 2007, David Lang wrote:
>
>> On Tue, 17 Apr 2007, Nicolas Pitre wrote:
>>
>>> I cannot do otherwise than ask at this point in the debate: why isn't
>>> the makefile rule sufficient for your needs?  Why going through a
>>> complicated path that no one else will support due to its numerous
>>> pitfalls?
>>
>> not all uses of VCS's involve useing make
>
> Use perl then.  Or a shell script.  Or even a command.com batch script.
> Or your own tool.

I would like to, however this doesn't currently integrate well with git. I've been told in the past that once .gitattributes is in place then the hooks for the crlf stuff can be generalized to allow for calls out to custom code to do this sort of thing.

however now it sounds as if people are saying that doing this is so evil that it shouldn't ever be allowed.

Show 16 quoted lines

>>>> That's just being obtuse - no other tool cares in the slightest about
>>>> the keywords, there are more "tools" in the world than just the VCS.
>>>
>>> ... which reinforces my question: why force a task on the VCS if it
>>> doesn't fit well with its fundamental design?
>>
>> becouse the VCS can do the job better then anything else?
>
> On what basis?
>
>> even if there are
>> limits to what the VCS can do.
>
> In the context of keyword expansion I don't agree at all with this
> statement.  Git can *not* do better than an external tool and it has
> been demonstrated a few times already.

the VCS can make sure that the appropriate external code is always run when things are checked in/out. external tools (unless they are a complete set of wrappers for git) can't do that.

David Lang