git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Cristian Le <cristian.le@mpsd.mpg.de>
To: "René Scharfe" <l.s.r@web.de>, git@vger.kernel.org
Subject: Re: Bug in git archive + .gitattributes + relative path
Date: Fri, 3 Mar 2023 16:38:59 +0100	[thread overview]
Message-ID: <8d04019d-511f-0f99-42cc-d0b25720cd71@mpsd.mpg.de> (raw)
In-Reply-To: <c7b21faa-68dd-8bd9-4670-2cf609741094@web.de>

[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]

> 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:
> 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é
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4273 bytes --]

  reply	other threads:[~2023-03-03 15:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 10:25 Bug in git archive + .gitattributes + relative path Cristian Le
2023-03-03 15:19 ` René Scharfe
2023-03-03 15:38   ` Cristian Le [this message]
2023-03-04 13:58     ` René Scharfe
2023-03-04 15:11       ` Cristian Le
2023-03-05  9:32         ` René Scharfe
2023-03-06 16:56       ` Junio C Hamano
2023-03-06 17:51         ` René Scharfe
2023-03-06 17:27       ` Junio C Hamano
2023-03-06 18:28         ` René Scharfe
2023-03-06 18:59           ` Junio C Hamano
2023-03-06 21:32             ` René Scharfe
2023-03-06 22:34               ` Junio C Hamano
2023-03-11 20:47                 ` René Scharfe
2023-03-12 21:25                   ` Junio C Hamano
2023-03-18 21:30                     ` René Scharfe
2023-03-20 16:16                       ` Junio C Hamano
2023-03-20 20:02                       ` [PATCH] archive: improve support for running in a subdirectory René Scharfe
2023-03-21 22:59                         ` Junio C Hamano
2023-03-24 22:26                           ` René Scharfe
2023-03-24 22:27                         ` [PATCH v2] archive: improve support for running in subdirectory René Scharfe
2023-03-27 16:09                           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d04019d-511f-0f99-42cc-d0b25720cd71@mpsd.mpg.de \
    --to=cristian.le@mpsd.mpg.de \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).