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