[RFC] archive: behavior of --prefix with absolute or parent path components

[Pushkar Singh <pushkarkumarsingh1970@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Hi,

While experimenting with "git archive", I noticed some behavior around
the --prefix option that might be worth clarifying.

Currently, --prefix accepts values such as absolute paths or ones with ..,
e.g.:
    git archive --prefix=/ HEAD > out.tar
    git archive --prefix=//// HEAD > out.tar
    git archive --prefix=../../ HEAD > out.tar

Upon listing the archive contents (e.g., tar -tf), you get entries like:
    /a.txt
    ////a.txt
    ../../a.txt

In such cases, tar emits warnings like:
    "Removing leading '/' from member names"
    "Removing leading '../' from member names"

This suggests that Git passes the prefix through as-is, relying on 
downstream tools to sanitize potentially unsafe paths.

From a user perspective, I was wondering:
  - Is this behavior intentional (i.e., leaving validation to archive
    consumers)?
  - Would it be worth documenting this explicitly?
  - Or should there be any normalization or validation at the Git level?

I understand that Git generally avoids enforcing policy decisions in 
such cases, but I wanted to confirm whether this behavior is intentional.

I’d appreciate any thoughts on this :-)

Thanks,
Pushkar