From: Junio C Hamano Date: Mon, 26 Sep 2011 04:09:31 GMT Subject: Re: How to use git attributes to configure server-side checks? Message-ID: <7vwrcwq70k.fsf@alter.siamese.dyndns.org> In-Reply-To: <4E7DB916.6010606@alum.mit.edu> Michael Haggerty writes: > On 09/24/2011 08:15 AM, Jeff King wrote: > For most software projects, the user does > > git pull > make > > daily. There is nothing that a nasty .gitconfig can do that can't be > done more easily by a nasty Makefile (or anything else in the build > process). The moment I pull from Junio's repository and run a build > without having personally done a full code review first, I've given > Junio complete pownership of my account. I suspect that argument is somewhat leaky. Will I be the _only_ one you will be pulling from? What if I were not so careful and relay a contaminated in-tree configuration file (which I would never use myself) to trusting downstream users like you? >> I'm not sure it makes sense to have it in the tree at all. For >> attributes it makes sense, because you are annotating a path at a >> _specific_ revision. But config is often much more meta- than that. >> Take textconv for an example. The gitattributes say "foo.pdf should use >> the 'pdf' diff driver". That makes sense to go in a revision. But the >> config will say "pdf files can be converted to text using >> /usr/bin/pdftotext". That is not something that is tied to the revision >> at all, and should exist outside of any revision. I.e., whether I am >> doing a "git show" on the HEAD, or on some ancient commit, I would want >> to use the same value, not whatever tool I used to convert PDFs years >> ago. I agree 100% with Peff on this point. What pdfviewer is configured to be used for my repository is tied closely to what I happen to have installed on my box that I use that repository on. This is not by accident but by design why attributes only specify what _kind_ of payload is in the path, and leave it up to the config to say _how_ to handle each kind of payload on the box).