Function holds_a_key 

pub fn holds_a_key(content: &[u8]) -> bool

Whether content is one of this tool’s key files, in either shape.

For the diff driver, which git hands arbitrary paths and which prints what it reads. A key file carries neither the data magic nor anything else that would stop it going straight to stdout, and git-xcrypt diff <key> > k would put it in the working tree, one git add -A from a commit. Deciding on the content rather than on the location is what makes the refusal hold for an exported copy, for a hard link and whatever the current directory is.

It has to recognise exactly what decode_portable accepts, which is why both go through [significant_lines] rather than each having their own idea of where the file starts. Measured before that: one # my laptop line above the header — the annotation a key picks up in a password manager, and a shape this module has a test for — made the header stop being the first byte, so the check missed it and git-xcrypt diff printed the repository’s master key in base64 with exit code 0. A leading blank line and leading spaces did the same. All three still imported as a working key.

Content that is not UTF-8 cannot be a portable key at all: read_portable reads the file as text, so such a file would never be accepted as one.