Re: Bug in git archive + .gitattributes + relative path

From: Cristian Le <cristian.le@mpsd.mpg.de>
Date: Mar 3, 2023, 15:38 UTC
Message-ID: <8d04019d-511f-0f99-42cc-d0b25720cd71@mpsd.mpg.de>
In-Reply-To: <c7b21faa-68dd-8bd9-4670-2cf609741094@web.de>

> In your issue #444 you write that "git archive HEAD" works, but "git archive HEAD:./" doesn't. Why do you need to use the latter?

Specifically we want to allow for `HEAD:./sub_dir` where `./sub_dir` contains `.gitattributes` and `.git_archive.txt`.

Alternatively, it would be helpful if we can pass `--transform` commands of `tar` directly so that we can change the paths.

Overall what we are doing in tito is that the source would be in `./src` and outside is metadata like `./my_package.spec`. We are using `git archive HEAD:./src --prefix=my_package-1.0.0` to pass the appropriate form that the rpm spec file can locate. In a tar command we can use `--transform=s|^src/|my_package-1.0.0/|` to achieve the equivalent. However we cannot use the `tar` directly because that would affect the timestamps and permissions of the file that are set by `git archive`.

So allowing for something like `git archive HEAD --transform=s|^src/|my_package-1.0.0/|`, where the transform is done after `.gitattributes` is performed would solve this issue.

On 2023/03/03 16:19, René Scharfe wrote:

Show 67 quoted lines

> External Email
> ________________________________
>
> Am 03.03.23 um 11:25 schrieb Cristian Le:
>> Using `git archive` with or without `--worktree-attributes` does not properly read `.gitattributes` files if using a relative path in `<tree-ish>`.
>> Related github comment: https://github.com/rpm-software-management/tito/pull/445#issuecomment-1450298871
>> Related stackoverflow discussion: https://stackoverflow.com/questions/52804334/how-to-ignore-files-directories-in-git-archive-and-only-create-an-archive-of-a
>>
>> Git version: `2.39.2`
>> Mwe git repo: Two files:
>> ```
>> # .gitattributes:
>> .git_archival.txt export-subst
>> ```
>> ```
>> # .git_archival.txt:
>> node: $Format:%H$
>> ```
>>
>> Commands to reproduce and expected behaviour:
>> ```console
>> $ git archive HEAD:./ --output=test.tar.gz
>> $ tar -axf test.tar.gz .git_archival.txt -O
>> node: 745ce26169fb44e04d91d40ee581cccd591c941e
>> ```
>> Important: Notice the path `./` given after `HEAD`.
>>
>> Actual output:
>> ```console
>> $ tar -axf test.tar.gz .git_archival.txt -O
>> node: $Format:%H$
>> ``>
>> It doesn't matter if `.gitattributes` is in a subfolder, or if I change the relative path `./` to a subfolder, the files are still not properly generated.
>>
>> Using `--worktree-attributes` did not have any effect either.
> That's expected behavior.  You specify a tree (HEAD:./), while
> export-subst requires a commit.  git-archive(1) doesn't spell that out,
> but advises to "See gitattributes(5) for details.", which states: "The
> expansion depends on the availability of a commit ID, i.e., if
> git-archive(1) has been given a tree instead of a commit or a tag then
> no replacement will be done.".
>
> The other attribute supported by git archive, export-ignore, does not
> require a commit.
>
> The Stack Overflow discussion seems to be about a different issue:
> Attributes are always based on the repository root directory, which
> gives unexpected results when archiving a subtree.
>
>> According to the documentation, I understand that the expected behaviour with regards to `--worktree-attributes`:
>> - Read the `.gitattributes` of the relative path, e.g. `./sub_dir` regardless of `--worktree-attributes`. (similar behaviour as not passing a relative path)
>> - Include the `.gitattributes` of the top-level path if `--worktree-attributes` is passed
>>
>> Maybe the intended behaviour is to completely ignore all `.gitattributes` unless `--worktree-attributes` is provided, in which case, it does not have the intended behaviour and please include a flag to achieve the above behaviour.
>>
> The option --worktree-attributes allows uncommitted .gitattribute files
> to be read, but has no effect on whether export-subst can actually be
> applied.
>
> So on the Git side we could improve the documentation and improve
> reading attributes when archiving subtrees (no idea how, though,
> admittedly).  But that wouldn't help you, I suppose.  In your issue
> #444 you write that "git archive HEAD" works, but "git archive HEAD:./"
> doesn't.  Why do you need to use the latter?
>
> René
>