We have an existing repository_badcommit table which is used to mark commits as "bad", where "bad" approximately means "the repository as a whole works, but the VCS tools can not read or should not read this particular commit for whatever reason". This is rare, but can happen when, e.g., third-party tools are used to write into repositories.

I originally implemented this at Facebook because some commits there (resulting, as I recall, from merging multiple SVN repositories, then bridging SVN to Git, all with third-party tools) just didn't work. I don't recall the specific nature of the failure, but it was easier to write these commits off than try to work around it (they were a handful of old commits from around the time the repositories were merged, years in the past).

Someone at Facebook also deleted a root directory by accident in SVN, which affected 78M paths or something like that. The next change reverted it. Although I believe I did import those commits, the Diffusion UI at the time choked when trying to display them so I think I just marked them bad and moved on. Diffusion is more capable of handling this situation today, but probably still doesn't handle it with any particular grace or elegance.

There's no tooling to write to this table, and I believe it has only come up once or twice since 2011.

I'm planning to merge the idea of "bad commit" and "rewritten commit" into a new "hint" table, something like this:

<repositoryPHID, oldCommit, newCommit?, hintType>

...where hintType is one of "bad" or "rewrite" today. This should let us reduce how weird and hacky the badcommit table is, and I can provide some unified tooling around accessing this table to make it more reasonable for users to update and for us to test.

It's sort of odd that this information isn't just in the commit table (e.g., a "bad" flag on the commit), but I can come up with a few somewhat-plausible arguments for keeping it separate:

• Write semantics for the commit table are complicated because of writes by the daemons, and keeping this separate sidesteps that issue.
• Although I plan to provide tooling, this is a pretty advanced feature and installs may reasonably want to just write to the table directly rather than go through whatever bin/repository hint API I put on top of it, particularly if they're rewriting very large numbers of commit hints.
• Putting this in a separate table allows us to query for rewrites when looking at the new commit, so we could show "This commit was rewritten from XYZ.". Although I don't currently plan to do this (it would have a small performance cost and I don't think it's actually useful?), it's something we might want to do in the future.

I don't think these arguments mandate a separate table, but I think we're on firm enough ground to comfortably keep the table separate.

So my plan is:

• Introduce this new table.
• Migrate badcommit to it, and drop badcommit.
• Provide bin/repository hint for writing new hints.
• Support a rewrite hint type.
• Document the existence of repository hints.

I also have a bit of a vague plan for dealing with the handle/PHID side of this, but want to research that in slightly more detail before writing up anything concrete.