fix: reject a lone '@' as a reference name, like Git does

[Amey Pawar (ameyypawar)]

Created by Claude Code on behalf of Amey, who reviewed it before submitting. Everything below this line is the agent's writing, not his.

---

Summary

• Reject a reference name consisting solely of @, which Git refuses because @ is shorthand for HEAD.
• Replace it with - when sanitizing, which is what Git's sanitizer does.
• Leave @ valid as a component, so refs/heads/@ and a tag named @ are unaffected.

Git baseline

check_or_sanitize_refname() in refs.c, which check_refname_format() delegates to, rejects the name outright and substitutes - in its sanitizing path. git check-ref-format refuses @ under every flag combination — plain, --allow-onelevel, --refspec-pattern, both together, and --normalize — while accepting refs/heads/@, refs/tags/@, @/x and @@.

The visible consequence was in refspec destinations:

$ git push origin "HEAD:@"
fatal: invalid refspec 'HEAD:@'

where gix_refspec::parse("HEAD:@", Push) returned Ok(dst = "@"). Sources were already right, since parse() rewrites a bare @ source to HEAD, but destinations reach reference::name_partial() directly.

Two public behaviours change as a result: name_partial_or_sanitize("@") now yields "-" rather than "@", and name("@") reports Reserved where it previously reported SomeLowercase. No caller in the workspace observes either.

Validation

A differential sweep of 1,030 reference names against git 2.52.0 — every byte 0x01–0xFF embedded in a component and as a whole component, plus .lock placement, slash density, dot placement and @{ forms — found @ to be the only divergence, and none remaining afterwards. Two shapes lie outside what the oracle can express: names containing NUL, and names beginning with -, which git check-ref-format will not accept as an argument.

• cargo test — gix-validate 326, gix-ref 179, gix-refspec 76, gix-revision 112, gix-object 148, gix-url 144, gix-worktree 10, gix 417
• cargo clippy -p gix-validate --all-targets
• cargo fmt --check

[Sebastian Thiel (Byron)]

Thank a lot, good catch! Very subtle behavior, and it still surprises me that @ as tag name is allowed. It actually can't be looked up as revspec directly, one will need tags/@ to disambiguate, but nothing informs about the ambiguity either. Interesting niche case, moving on 😅.