Hi, On Thu, Aug 12, 2010 at 00:19, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Have you read the comment at the top of prepare-attr-stack? This patch > feels triply wrong: > > - The attribute stack is arranged to have higher precedence file near the > top ($GIT_DIR/info/attributes used to be the highest). The above > addition means that ~/.gitattributes from user's home trumps what is in > a particular repository. That is backwards. You may work on more than > one projects and have more than one repositories. What you share among > them personally will go to ~/.gitattributes, while a setting specific > to a particular repository goes to $GIT_DIR/info/attributes and the > latter needs to be able to override the former. > > - Same thing for git_attr_system() being at the end, which means you set > up your own $GIT_DIR/info/attributes (or ~/.gitattributes) carefully > but that can be broken by a selfish sysadmin who puts stuff that is > only useful to him in /etc/gitattributes, which is not what you want. > > - Whenever we enter a new directory (either recursing into, or coming > back up), prepare_attr_stack() is called to pop the attributes records > from now-exited directories and push the attributes records from > directories we are about to descend into. The current code knows that > the topmost element on the stack is special ($GIT_DIR/info/attributes) > and first pops it, adjust the stack for elements that came from the > directory hierarcy, and then pushes that back. I don't see any code in > the patch to do the equivalent for these two new attribute sources. Yeah, I realize now that I got the precedence wrong, the corrected patch is in the following email. But to your third point, I read the comment and the code worked, because I put all the attributes from the 3 files into one attr_stack struct (the one at the top of the stack). That's why I changed read_attr_from_file too. Of course this is irrelevant now that those attributes will be at the bottom of the stack. Petr Onderka -- 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