Facade not correctly populating author name in commits table

[MoralCode]

While investigating #3693, We (the maintainers) noticed that far too many entries in the commits table were missing author names. Since this table has a NOT NULL constraint on this column, "missing" here means "is set to empty string"

Observations

• we manually ran the git CLI used to grab the commit log data against a local clone of the augur repo and a specific unresolved commit and confirmed the git CLI was returning the information correctly.
• we didnt see any logic errors that seemed problematic in the text parsing of the author name (i.e. up until it gets added to the dict that presumably gets INSERTed eventually)
  • we did however, notice that there is part of the text parsing code that includes an author_name or '' line, which could be what is inserting the empty string, we just werent sure how
• we briefly checked that the column names match between the dict and the table they were going into
• This seemed to correlate a fair bit with having the committer information be attributed to a bot, but dont read into this too much

[MoralCode]

AI analysis that seems plausible and not caught by our manual testing:

The git log --pretty=format: argument is (very likely) being quoted incorrectly
You’re calling git log via subprocess.check_output([...]) (no shell), but you also embed single quotes inside the argument:
analyzecommit.py
Lines 152-166
git_log = check_output( [f"git", "--git-dir", repo_loc, "log", "-p", "-M", commit, "-n1", f"--pretty=format:'{pretty_format}'"])
Because this is not executed through a shell, those '...' are not stripped. They become part of the literal pretty-format string, so the output lines typically start with a leading ', e.g.:
"'author_name: Jane Doe" (note the first character is a ')
…but your parser only matches lines that start exactly with author_name::

[sgoggins]

Oof. I think I know who has the git blame on that one. Me.

[MoralCode]

as mentioned in that issue, we need more robust checking for data sanity before committing something to the DB. we are currently relying on LOTS of assumptions that are pretty much all apparrently able to be bypassed when a bug like this causes a commit author name to be an empty string and therefore a match with every other commit author/contributor name thats also subject to this bug

@sgoggins this error with the quotes has likely been present in databases for a long time. we likely need queries that can

1. check for whether people are affected by this (i.e. look for an abnormal, >10, number of aliases per contributor/fetch all contributors with more than that many aliases.
2. find the best way to remediate the problem (is that resetting facade and having it re-process all commits? and then redoing contributor resolution for everything? is that a specialized cleanup script to selectively reprocess problematic entries?)

[MoralCode]

query to measure how broken a database is

WITH counts AS (
    SELECT 
        ca.cntrb_id, 
        count(*) as count,
        COUNT(distinct ca.alias_email) AS distinct_count 
    FROM augur_data.contributors_aliases ca 
    GROUP BY ca.cntrb_id
)
SELECT 
    counts.cntrb_id, 
    counts.count as alias_count,
    counts.distinct_count,
    c.* -- or specific columns from the contributors table
FROM counts
JOIN augur_data.contributors c ON c.cntrb_id = counts.cntrb_id
ORDER BY distinct_count DESC;

(this shows the contributors table with a column counting the number of aliases per contributor, sorted highest first)

after identifying a possibly problematic contributor with too many aliases, this can be used to show all aliases given a contributor id:

select * from augur_data.contributors_aliases ca where ca.cntrb_id ='<TARGET ID HERE>'::uuid

[MoralCode]

So this was my fault.... This PR changed how we shell out to git in a way that explains the breakage #3232