I'm going to close this as "Wontfix". Although adding custom fields is something we may still do, I no longer expect to "rebuild" on top of that infrastructure.

This task was filed shortly after CustomFields were written when it looked like we might move all object fields onto that infrastructure, but their design ultimately evolved in a different direction, largely into EditEngine. Comparatively, CustomFields are more monolitic (one field definition controls all behavior) while EditEngine is more flexible (a larger number of smaller pieces are composed to create overall behavior). CustomFields were the first major step in this direction, but EditEngine and supporting infrastructure, like ModularTransactions, ultimately feel like they are better fits to the problem space.

Diffusion now (mostly) uses EditEngine, per T10978, so we effectively skipped a rebuild on custom fields.

We could still add custom fields to Diffusion, but the use cases aren't terribly clear and this task doesn't meed the modern standard for describing root problems. In particular:

• This task mentions "Projects", but they've been supported for some time.
• This task mentions "Bug ID", but the scope of that isn't clear. It seems unlikely that an actual custom field is the best fit.
• We haven't, as far as I know, seen other specific interest in adding other mutable fields to commits.
• In cases where the goal is just to parse information out of commits, an integration with Differential fields alongside T9713 probably makes more sense.

If you have a use case which you believe might be addressed by this, please file a new feature request following Contributing Feature Requests and we can figure out how to tackle it.