Hi brian, On Mon, 23 Mar 2020, brian m. carlson wrote: > On 2020-03-23 at 13:08:44, Johannes Schindelin via GitGitGadget wrote: > > 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. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > Ignore the global PAX header in import-tars.perl > > > > This problem came up in Pacman-related work, where PKGBUILD definitions > > would reference the tarballs downloaded from GitHub, and patches would > > be applied on top. To work on those patches efficiently (e.g. when an > > upgrade to a new version of the project no longer lets those patches > > apply), I need to be able to import those tarballs into playground > > worktrees and work on them. I like to use > > contrib/fast-import/import-tars.perl for that purpose, but it really > > needs to strip the prefix, otherwise it is too tedious to work with it. > > > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-577%2Fdscho%2Fimport-tars-skip-pax-header-v1 > > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-577/dscho/import-tars-skip-pax-header-v1 > > Pull-Request: https://github.com/gitgitgadget/git/pull/577 > > > > contrib/fast-import/import-tars.perl | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl > > index e800d9f5c9c..d50ce26d5d9 100755 > > --- a/contrib/fast-import/import-tars.perl > > +++ b/contrib/fast-import/import-tars.perl > > @@ -139,6 +139,8 @@ > > print FI "\n"; > > } > > > > + next if ($typeflag eq 'g'); # ignore global header > > + > > In general, it isn't safe to do this. A pax global header contains > attributes that may live in a normal extended header at a lower > priority. So it is valid, for example, to write an mtime field in the > global header that applies to the entire archive and overrides the > ustar header block (and is overridden by a normal extended header). > > I think we need a different solution for this case. I agree that we need a different solution for this case. At the same time, I would like to point out that I am trying to address a _different_ problem than "we're not using the information contained within the PAX global header": I want to prevent that header from polluting the top-level tree. For what it's worth, my patch does not prevent future patches from using the information contained within the global header :-) Thanks, Dscho
