Re: [PATCH 2/2] Add keyword unexpansion support to convert.c
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Apr 17, 2007, 20:53 UTC
- Message-ID
- <Pine.LNX.4.63.0704171352280.1696@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <alpine.LFD.0.98.0704171708360.4504@xanadu.home>
On Tue, 17 Apr 2007, Nicolas Pitre wrote:
Show 31 quoted lines
> Subject: Re: [PATCH 2/2] Add keyword unexpansion support to convert.c > > On Tue, 17 Apr 2007, David Lang wrote: > >> On Tue, 17 Apr 2007, Nicolas Pitre wrote: >> >>> 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. > > And I agree that this is a perfectly sensible thing to do. The facility > should be there for you to apply any kind of transformation with > external tools on data going in or out from Git. There are good and bad > things you can do with such a facility, but at least it becomes your > responsibility to screw^H^H^H^Hfilter your data and not something that > is enforced by Git itself.
I'm pretty sure that hooks for an external helper would satisfy Andy with his keyword expanstion as well.
David Lang