Hi René, On Mon, 23 Mar 2020, René Scharfe wrote: > 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. The tar importer in `contrib/fast-import/import-tars.perl` has a very convenient feature that I took for public knowledge: if _all_ paths stored in the imported `.tar` start with a common prefix, e.g. `my-project-1.0.0/` as indicated in the commit message (or `git-2.26.0/` in the tar at https://github.com/git/git/archive/v2.26.0.tar.gz), then this prefix is stripped. This feature makes a ton of sense because it is relatively common to import two or more revisions of the same project into Git, and obviously we don't want all files to live in a tree whose name changes from revision to revision. Now, the problem with that feature is that it breaks down if there is a `pax_global_header` "file" located outside of said prefix. > 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? Exactly. Thanks, Dscho > > Thanks, > René > >
