On 10/04/2011 08:52 PM, Gioele Barabucci wrote: > I just updated to git v1.7.7 using the Ubuntu Lucid PPA and I found that > `git check-attr` is broken now. > > I have this attribute in my `$HOME/.gitattributes` file: > > /. show_in_prompt=no > > Now, if I go to `$HOME` and run > > git check-attr show_in_prompt -- . > > With git v1.7.6 this is the answer I got: > > .: show_in_prompt: no > > With the newer v1.7.7 I get this, instead: > > .: show_in_prompt: unspecified > > Also, if I use the `--all` option, `check-attr` does not show any > attribute at all. > > I see in the release notes of 1.7.7-rc1 that `check-attr` has been > changed to allow relative paths to be specified. Maybe this error is > related to that change. Indeed, your use case is broken by f5114a40c0d0276ce6ff215a3dc51eb19da5b420 In fact the support for gitattributes using patterns involving "." was pretty spotty in v1.7.6 too. For example, ------------------------------------------- echo ". foo" >./.gitattributes git check-attr foo -- . ./ ./. x x/ ./x x/. .: foo: set ./: foo: unspecified WRONG ./.: foo: set x: foo: unspecified WRONG? x/: foo: unspecified WRONG? ./x: foo: unspecified WRONG? x/.: foo: set RIGHT? ------------------------------------------- echo "/. foo" >./.gitattributes git check-attr foo -- . ./ ./. x x/ ./x x/. .: foo: set ./: foo: unspecified WRONG ./.: foo: set x: foo: unspecified x/: foo: unspecified ./x: foo: unspecified x/.: foo: unspecified ------------------------------------------- echo ". foo" >x/.gitattributes git check-attr foo -- . ./ ./. x x/ ./x x/. .: foo: unspecified ./: foo: unspecified ./.: foo: unspecified x: foo: unspecified WRONG? x/: foo: unspecified WRONG? ./x: foo: unspecified WRONG? x/.: foo: set RIGHT? ------------------------------------------- echo "/. foo" >x/.gitattributes git check-attr foo -- . ./ ./. x x/ ./x x/. .: foo: unspecified ./: foo: unspecified ./.: foo: unspecified x: foo: unspecified WRONG x/: foo: unspecified WRONG ./x: foo: unspecified WRONG x/.: foo: set ------------------------------------------- I conclude that this functionality was never really defined correctly, and you were pretty lucky that your case worked at all :-) It's not to hard to fix your particular use case. But for a real fix, we would need to decide what is the correct behavior in all of the lines above marked "?"; specifically, should "." match every subdirectory under a given directory, does it match only the directory containing the .gitattributes file, or is this construct illegal? 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