Log() throws GitParseException for the whole history if any commit has an empty author/committer email (e.g. `<>`)

[matt-edmondson]

What's wrong

GitLogParser (GitIntegration/Parsing/GitLogParser.cs, lines ~63 and ~69) parses the author email and the committer email with GitParseValues.ToSemantic<GitAuthorEmail>. That method rejects an empty string, and GitAuthorEmail also carries [HasNonWhitespaceContent].

Git itself accepts commits with an empty email:

• git -c user.name=a -c user.email= commit --allow-empty -m x succeeds.
• git log -1 --format='[%an][%ae]' then prints [a][].

Commits like this, with an empty <> email, are common in imported histories (svn/cvs conversions, git fast-import, commit-tree, bots).

Failure scenario

Call repo.Log().ExecuteAsync() on any repository whose history contains one such commit. The whole call fails:

GitParseException: git reported a author email that is not valid: ''.

The caller gets no commits at all, not even the valid ones. One bad commit anywhere in the range makes Log() unusable for that repository. An empty author or committer name, which fast-import / commit-tree can also produce, fails the same way.

Suggested fix / acceptance criteria

• Let GitSignature.Email represent "no email". Either make it nullable (GitAuthorEmail?), or drop HasNonWhitespaceContent from GitAuthorEmail.
• Parse fields 3, 4, 6 and 7 with a helper that maps "" to null (or to empty) instead of throwing.
• Add a test that builds a commit with user.email= (and one with an empty name via commit-tree) and asserts that Log() returns it.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. One commit with an empty author or committer email (or name) makes Log() fail for the whole range and return nothing. Such commits are common in svn/cvs imports, fast-import and bot histories, so some real repositories cannot use Log() at all.
• Area / suggested assignee: GitLogParser (fields 3, 4, 6 and 7) and GitSignature / GitAuthorEmail ([HasNonWhitespaceContent]). Owner: @matt-edmondson
• Duplicates / in progress: not a duplicate. It follows the same pattern as Status()/Diff()/Patch() throw for the whole repo when any path contains <, > or |, or is longer than 256 characters (legal on Linux/macOS) #131: strict semantic validation on values git reports turns one odd entry into a whole-verb failure. No open PR.
• Next step: make GitSignature.Email (and the name) nullable, or relax the attribute, and parse empty fields to null. Add the user.email= and commit-tree empty-name tests. It is also worth checking the other parsers for a strict ToSemantic on values git can legitimately leave empty.

---

Generated by Claude Code