There are multiple problems.

Auto_inc of 922M is half way to the 2 billion limit on `INT SIGNED`.  Suggest you change to `INT UNSIGNED` (4 billion limit) during the next `ALTER`.

MyISAM saves disk space, but is otherwise 'worse' than InnoDB.  Note:  changing to InnoDB will require changing several settings.

`FOREIGN KEYS` are ignored by MyISAM.

If `sha` is a SHA-1 hash, it is terrible for indexing.

If `sha` is a SHA-1 hash, it could be compressed to `BINARY(20)` via `UNHEX()`.  This would shrink the table by over 20GB, 30% of the current size!

If `sha` is a SHA-1 hash, don't use utf8; use ascii or latin1.

If `sha` is a SHA-1 hash, and that is the column you are creating the `UNIQUE` index on, check `SHOW PROCESSLIST`.  If it says "Repairing by key_buffer", then you should kill it; it will take days or weeks to finish.  If it says "Repairing by sort", then there is hope that it will finish.

Consider using smaller ids than the 4-byte INT for author, committer, and project -- unless you really have many billion distinct values.  Wait!  What?  Each of those is going to be `UNIQUE`?  I doubt it.

What `SELECTs` do you have?  Might some of them need 'composite' indexes?

Put multiple `ALTERs` (including creating indexes) into a single statement.  Each `ALTER` is a complete copy of the table (in MyISAM).

`myisam_sort_buffer_size = 8G` is half of RAM.  This is bad.  Suggest 3G.