Re: git archive should use vendor extension in pax header

[fuz@fuz.su]

On Tue, Jan 26, 2016 at 11:06:25PM +0100, René Scharfe wrote:
> Am 24.01.2016 um 16:59 schrieb fuz@fuz.su:
> >Right now, git archive creates a pax global header of the form
> >
> >     comment=57ca140635bf157354124e4e4b3c8e1bde2832f1
> >
> >in tar archives it creates. This is suboptimal as as comments are
> >specified to be ignored by extraction software. It is impossible to
> >find out in an automatic way (short of guessing) that this is supposed
> >to be a commit hash.
> 
> This is only a problem if you don't know how a given tar files was
> created (or modified later).  How did you get into this situation?
> Or in other words: Please tell me more about your use case.

My situation is that I'm interested in knowing if an archive was created
by git so I can find out where the corresponding repository is and find
out which commit this archive was created from.  Right now the only way
is to open a hex editor or as archiving software is instructed to ignore
the content of comment headers.  This is clearly a suboptimal situation.

> >It would be much more useful if git created a
> >custom key. As per POSIX suggestions, something like this would be
> >appropriate:
> >
> >     GIT.commit=57ca140635bf157354124e4e4b3c8e1bde2832f1
> 
> This would be included in addition to the comment in order to avoid
> breaking existing users, I guess.

Good point.  I'm not sure how many user use the comment header at all.

> If you have a random archive and want to know if it was generated by
> git then your next question might be which options and substitutions
> were used.  That reminds me of this thread regarding verifiable
> archives:
> 
>     http://article.gmane.org/gmane.comp.version-control.git/240244

Good point.  Something like this should be enough to be enough to have
reproducable archives if archives with a tree ID were to have a time
stamp of 0 (1970-01-01) instead of the current date:

    comment=...    (for compatibility)
    GIT.commit=... (like comment)
    GIT.umask=...  (tar.umask)
    GIT.prefix=... (--prefix=)
    GIT.path=...   (see below
    GIT.export-subst=1 (in extended header instead of global header)

A different key such as GIT.treeish might be appropriate.  The
GIT.export-subst key should be set only for those files where a
substitution has taken place. Maybe there should also be an
GIT.original-name key.

An option GIT.export-ignore is not required.  Instead it would be more
useful to have a special file type G (for git) with the convention that
the file name .gitattributes means “attributes that apply to this git
archive.”

The GIT.path option holds the paths that are being archived. It is a bit
tricky to get right.  The intent of POSIX pax headers is that each key
is an attribute that applies to a series of files.  In the case of a
global header, each key applies until it is overridden with a new
header or with a local header.  A GIT.path key should only apply to the
files that correspond to this path operant to git archive.  Thus, a new
GIT.path should be written frequently.  There should always be at least
one GIT.path.

It might be a good idea to be able to control the kind of metadata git
adds to the archive as to be able to not leak any confidential
information with git archive.  If you are interested I can try to make a
specification for these headers.

Yours sincerely,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments