René Scharfe <l.s.r@xxxxxx> writes: > Am 23.03.20 um 14:08 schrieb Johannes Schindelin via GitGitGadget: >> From: Johannes Schindelin <johannes.schindelin@xxxxxx> >> >> Git's own `git archive` inserts that header, but it often gets into the >> way of `import-tars.perl` e.g. when a prefix was specified (for example >> via `--prefix=my-project-1.0.0/`, or when downloading a `.tar.gz` from >> GitHub releases): this prefix _should_ be stripped. >> >> Let's just skip it. > > git archive uses a global pax header to pass the ID of the archived > commit as a comment, and for mtime values after 2242-03-16. Ignoring it > in a simple importer seems reasonable for now, but I don't understand > how this relates to prefixes. Is it because the header is treated as a > regular file with the full path "pax_global_header" (independently from > any prefix for actual files) and can thus be placed outside the expected > destination directory? Thanks for asking the question, as I was also curious if we are throwing away too much (perhaps "prefix is given as a global pax header, and ignoring all global pax headers is the most expedite way" was the reason the patch was written that way?). I agree with you that for the purpose of simple-minded importer, it probably is acceptable to take such a short-cut, but it would help future developers if we clearly documented that it is a short-cut that throws too much. That would welcome their effort to enhance the importer, if they find it more useful to keep some other information found in global headers, without breaking the intent of this change. Having said all that, even before "git archive" existed, release tarballs by many projects had leading prefix so that a tarball extract would be made inside a versioned directory. To truly help users of the importer, doesn't the logic to allow the user to say "please strip one leading level of directory from all the tarballs I feed you, as I know they are versioned directories" belong to the command line option of the importer?
