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

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

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Aug 4, 2011, 04:47 UTC
Message-ID
<1312433268-11385-1-git-send-email-mhagger@alum.mit.edu>

This is a reroll of the earlier RFC. It must be applied on top of "Add --all option to git-check-attr" v3.

This re-roll differs in the following ways from the RFC:
* Adjusted for changes between the "--all" patch series v2 -> v3.
* Fixed some C problems found by Junio.

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.

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 7 in “git-check-attr should work for relative paths”
  1. 0/6 git-check-attr should work for relative pathsMichael Haggerty, Aug 4, 2011
  2. 1/6 git-check-attr: test that no output is written to stderrMichael Haggerty, Aug 4, 2011
  3. 2/6 git-check-attr: Demonstrate problems with unnormalized pathsMichael Haggerty, Aug 4, 2011
  4. 3/6 git-check-attr: Demonstrate problems with relative pathsMichael Haggerty, Aug 4, 2011
  5. 4/6 git-check-attr: Normalize pathsMichael Haggerty, Aug 4, 2011
  6. 5/6 test-path-utils: Add subcommand "absolute_path"Michael Haggerty, Aug 4, 2011
  7. 6/6 test-path-utils: Add subcommand "prefix_path"Michael Haggerty, Aug 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.