Re: Bug in git archive + .gitattributes + relative path
- From
René Scharfe <l.s.r@web.de>
- Date
- Mar 6, 2023, 18:28 UTC
- Message-ID
- <d16c6a22-05d8-182c-97b4-53263d22eaa6@web.de>
- In-Reply-To
- <xmqqcz5lbxiq.fsf@gitster.g>
Am 06.03.23 um 18:27 schrieb Junio C Hamano:
Show 39 quoted lines
> René Scharfe <l.s.r@web.de> writes: > >> Subject: [PATCH] archive: add --strip-components >> >> Allow removing leading elements from paths of archive entries. That's >> useful when archiving sub-directories and not wanting to keep the >> common path prefix, e.g.: >> >> $ git archive --strip-components=1 HEAD sha1dc | tar tf - >> .gitattributes >> LICENSE.txt >> sha1.c >> sha1.h >> ubc_check.c >> ubc_check.h >> >> The same can be achieved by specifying a tree instead of a commit and >> a pathspec: >> >> $ git archive HEAD:sha1dc | tar tf - >> .gitattributes >> LICENSE.txt >> sha1.c >> sha1.h >> ubc_check.c >> ubc_check.h > > 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().
René