Hello,
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.
Best,
--
Gioele Barabucci [off-list ref]
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@alum.mit.edu
http://softwareswirl.blogspot.com/
On 05/10/2011 14:05, Michael Haggerty wrote:
On 10/04/2011 08:52 PM, Gioele Barabucci wrote:
quoted
With the newer v1.7.7 I get this, instead:
.: show_in_prompt: unspecified
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
Wow, debug-by-changelog :)
In fact the support for gitattributes using patterns involving "." was
pretty spotty in v1.7.6 too. For example,
[...]
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?
I do not know what the correct behavior should be, but here is my use case.
I use git to version almost all my $HOME dir. In addition to my usual
files there are also separate project repositories under $HOME. I enjoy
using a git-enabled prompt in those projects' dirs but not in my $HOME dir.
So I have this code somewhere in my `~/.bashrc`:
local show_status="$(git check-attr show_in_prompt -- .)"
local show_pattern='^\.: show_in_prompt: (.*)$'
# add the following line to .gitattributes
#
# /. show_in_prompt=no
local show_in_prompt='yes'
if [[ ${show_status} =~ ${show_pattern} ]]; then
show_in_prompt="${BASH_REMATCH[1]}"
fi
if [ "${show_in_prompt}" == 'no' ]; then
return
fi
As you see in my the line of this code, I exploit the fact that "."
refers to the root git dir, not to the current dir, to simplify the
code. Otherwise I would had to discover what is the path of the current
dir relative to its root git dir, something that I'd like to avoid as
this code runs every time the prompt is shown.
This is just my personal use case. On the other hand, the first time I
looked at check-attr I found it strange that paths were meant as
relative to the root git dir ("." in "/foo" = "/") and not expanded from
the current dir ("." in "/foo" = "/foo").
Bye,
--
Gioele Barabucci [off-list ref]