René Scharfe [off-list ref] writes:

quoted

Another way I am not sure is working as designed is

    $ cd sha1dc && git archive HEAD . | tar tf -
    .gitattributes
    LICENSE.txt
    sha1.c
    sha1.h
    ubc_check.c
    ubc_check.hq

I didn't check if the attribute look-up is done on the correct path
or export-subst kicks in in such a use, though.

export-subst is supported in that invocation because git archive has a
commit to work with.

I can kinda see others preferring the directory prefix "sha1dc/" added
to those entries.  Perhaps it depends on what git archive is supposed to
archive: A commit or the files of a commit?  I'm in the latter camp, and
expect to see the same paths as given by git ls-files or git ls-tree.

But that invocation in a sub-directory probably has the same problem
with attributes as the one with a sub-tree above it, i.e. that
attributes are always looked up relative to the repository root.  I
wonder if 47cfc9bd7d (attr: add flag `--source` to work with tree-ish,
2023-01-14) provided the means to fix this when it added a tree_oid
parameter to git_check_attr().

It somehow feels that the use of pathspec in "git archive" is
somewhat iffy, e.g.

   $ cd sha1dc && git archive HEAD :/ | tar tf -

does not compare very well with

   $ cd sha1dc && git ls-tree -r HEAD :/

For that matter, replacing ":/" (full tree) with ".." (we know one
level above is the root of the working tree) has the same "why don't
they work the same way???" confusion.