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

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