pub struct UnnameableRef {
pub name: Vec<u8>,
pub reason: String,
pub position: usize,
pub deletes: bool,
}Expand description
A command line this server will not accept a name from.
§Why an invalid name is not an error
It used to be. read_commands called FullName::new with ?, so one bad
name aborted the whole session before the pack had been read: the client was
still writing and got a broken pipe, no report-status was ever produced,
and every other reference in the same push was lost with no line saying
which one was at fault. That is the the remote end hung up unexpectedly
shape, and it is the same defect the shallow-clone fix in read_commands
closed for one particular cause without closing the class.
Stock git defers it to the report, and this is measured, not assumed.
git receive-pack 2.53.0, 2026-08-06, fed a raw two-command push of
refs/heads/goodone and refs/heads/bad~name over one connection, answered:
unpack ok
ok refs/heads/goodone
ng refs/heads/bad~name funny refnameexit 0, refs/heads/goodone created. So the good reference lands, the bad
one is named in the report, and the session ends cleanly. gunnar now does
the same.
The name is kept as bytes: it is precisely a name the validator refused,
so there is nothing to hold it in, and it is echoed back verbatim because a
client matches the ng line against the name it sent. Since the contract’s
RefRow::name is a String, a name that is valid but not UTF-8 lands
here too — see ReceivePack::parse_command, which records that narrowing
rather than hiding it.
Fields§
§name: Vec<u8>The reference name exactly as the client spelled it.
reason: StringThe one-line reason, rendered into the ng line.
position: usizeWhere the line sat in the client’s command list, so the report can be emitted in the order the client sent — which is what git does and what a client zipping its own list against the report needs.
deletes: boolWhether the line asked for a deletion. A push carrying only unnameable deletes sends no pack, and a server that waited for one would hang.