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

From: Nicolas Pitre <nico@cam.org>
Date: Apr 18, 2007, 14:56 UTC
Message-ID: <alpine.LFD.0.98.0704181036280.4504@xanadu.home>
In-Reply-To: <7vlkgqjmsa.fsf@assigned-by-dhcp.cox.net>

On Tue, 17 Apr 2007, Junio C Hamano wrote:

Show 15 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Tue, 17 Apr 2007, Junio C Hamano wrote:
> >
> >> You have to be careful, though.  Depending on what kind of
> >> transformation you implement with the external tools, you would
> >> end up having to slow down everything we would do.
> >
> > So what?  
> >
> > We provide a rope with proper caveat emptor.  Up to others to hang 
> > themselves with it if they so desire.  It is not our problem anymore.
> 
> I sort-of find it hard to believe hearing this from somebody who
> muttered something about importance of perception a few days ago.

Sure!  And that applies in this case as well.

With such a _generic_ hook, Git will be perceived as much more powerful and flexible. I insist on "generic" because people could experiment with their own filters without endless debate on the mailing list and pressure to include this or that feature in the core, and we don't have to commit to those feature we're not in agreement with.

And let's face it: there are probably legitimate and possibly more useful things to do with such a hook than keyword expansion.

If you go to Home Hardware you can buy rope. Of course you can hang yourself with it, but the rope manufacturers won't commit to that I'm sure. But if rope was banned by law because it represents a threath to life then governments would be perceived really strangely even if their intention are good.

Sure we might have a strong opinion against keyword expansion and that is reflected by the fact that Git will most probably never ship with the ability to perform keyword expansion. That doesn't mean we should deny all possibilities for external filters _even_ if they can be used for keyword expansion.

Show 11 quoted lines

> >> I suspect that you would have to play safe and say "when
> >> external tools are involved, we need to disable the existing
> >> content SHA-1 based optimization for all paths that ask for
> >> them" to keep your sanity.
> >
> > Maybe.  If that is what's really needed then so be it.  People who 
> > really want to do strange things will have the flexibility to do so, but 
> > they'll have to pay the price in loss of performance.
> 
> Not just that.  We end up having to pay the price of maintaining
> hooks to let them do crazy things.

Weight that against the price of fighting them against the crazy things they won't quit wanting to do. At some point it is just a matter of getting out of the way.

Nicolas