Michael Haggerty <mhagger@xxxxxxxxxxxx> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html