On 01/10/2012 06:22 PM, Junio C Hamano wrote: > Regardless of this unrelated regression, after looking at what ec775c4 > wanted to do again, I am very much tempted to just revert it. > > It aimed to take these three > > * ident > foo mybin > bar mybin ident > > and wanted to omit 'ident' from "foo" when there is this macro definition > elsewhere: > > [attr] mybin binary -ident > > But the real point of the macro was that the users do not have to know > their internals, iow, if you explicitly specify a pattern that overrides > the contents of the macro, that explicit pattern should win. When deciding > the value of "ident" attribute for path "foo", "* ident" is stronger than > "foo mybin" (the latter of which does not say anything about 'ident' > explicitly). I like the simplicity of the rule "apply attributes in the order found in the .gitattributes files" better than the rule you are proposing, which seems like it will become more complicated to explain. For example, it would seem under your rule for the above example that the "mybin" macro should bestow on file foo the "binary" attribute and also the "mybin" attribute (given that macros are themselves attributes), but not "-ident". You would also have to decide and explain whether a macro that invokes a macro that sets or clears attribute "foo" is "weaker" than a simple macro that clears or sets attribute "foo". I have one real-life use case that would become more difficult with your rule: # Marker for textlike files whose EOL characters haven't been # normalized yet: [attr]eol-fixme -text !eol *.cc text eol=lf # Then later, perhaps in some subdirectory's .gitattributes: SomeParticularScrewedUpFile.cc eol-fixme The point of the eol-fixme macro is (1) to prevent git from throwing a tantrum and (2) to mark the file as needing cleanup sometime in the future. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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