git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC 0/6] git-check-attr should work for relative paths

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jul 28, 2011, 10:36 UTC
Message-ID
<1311849425-9057-1-git-send-email-mhagger@alum.mit.edu>

Currently, git-check-attr gets confused if it is passed certain types of unnormalized paths or is invoked from a non-top-level directory. For example, using the test repo created by t0003-attributes.sh, inquiring about a path that starts with "./" causes git-check-attr to emit a spurious warning:

    $ git check-attr test ./f
    [attr]notest !test
     not allowed: ./.gitattributes:1
    ./f: test: f
    $ git check-attr test ./a/i
    [attr]notest !test
     not allowed: ./.gitattributes:1
    ./a/i: test: a/i

In these cases it seems to find the right values, even including the application of macros from the top-level .gitattributes file. (My guess is that it is loading the top-level .gitattributes file twice--once as a top-level file, and once believing that it is in a subdirectory.)

Invoking git-check-attr from a subdirectory using a relative path gives incorrect answers; for example:

    $ (cd a; git check-attr test i )
    i: test: unspecified

(On the other hand, if invoked using the full path of a file, it "works":

    $ (cd a; git check-attr test a/i )
    a/i: test: a/i

.) I think that this behavior is confusing and inconsistent with other git commands. It is also inconsistent with the behavior of .gitignore, which works from subdirectories.

The patches in this series add tests demonstrating the problem, propose a possible solution, and add a couple of subcommands to test-path-utils.

I am far from confident that the solution proposed in patch 4 is correct; please see the notes in that email for discussion.

The changes to test-path-utils helped me figure out how the corresponding functions work (comments? we don't need no stinkin' comments) but they are not used anywhere. Take 'em or leave 'em.

Michael Haggerty (6):
  git-check-attr: test that no output is written to stderr
  git-check-attr: Demonstrate problems with unnormalized paths
  git-check-attr: Demonstrate problems with relative paths
  git-check-attr: Normalize paths
  test-path-utils: Add subcommand "absolute_path"
  test-path-utils: Add subcommand "prefix_path"
 builtin/check-attr.c  |   20 ++++++++++++--------
 t/t0003-attributes.sh |   29 ++++++++++++++++++++++++++---
 test-path-utils.c     |   22 ++++++++++++++++++++++
 3 files changed, 60 insertions(+), 11 deletions(-)
-- 
1.7.6.8.gd2879
Next: Michael Haggerty
Message 1 of 15 in “[RFC 0/6] git-check-attr should work for relative paths”
  1. Michael HaggertyJul 28, 2011
  2. 1/6 git-check-attr: test that no output is written to stderrMichael Haggerty, Jul 28, 2011
  3. 2/6 git-check-attr: Demonstrate problems with unnormalized pathsMichael Haggerty, Jul 28, 2011
  4. 3/6 git-check-attr: Demonstrate problems with relative pathsMichael Haggerty, Jul 28, 2011
  5. 4/6 git-check-attr: Normalize pathsMichael Haggerty, Jul 28, 2011
  6. Junio C HamanoAug 2, 2011
  7. Michael HaggertyAug 4, 2011
  8. Junio C HamanoAug 4, 2011
  9. Michael HaggertyAug 5, 2011
  10. Junio C HamanoAug 5, 2011
  11. Michael HaggertyAug 7, 2011
  12. 5/6 test-path-utils: Add subcommand "absolute_path"Michael Haggerty, Jul 28, 2011
  13. 6/6 test-path-utils: Add subcommand "prefix_path"Michael Haggerty, Jul 28, 2011
  14. Junio C HamanoAug 2, 2011
  15. Michael HaggertyAug 4, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.