[lbluque]

Summary

job.metadata.commit already identifies the code a run was trained with, but only as a hash, and only when fairchem.core sits in a git repo — a released install has no repo, so get_commit_hash() reports core:None.

This adds two more read-only fields next to it, both populated in JobConfig.__post_init__:

• metadata.branch — from git branch --show-current in the fairchem.core checkout. None for a released install and for a detached HEAD, neither of which has a branch to report.
• metadata.version — the installed fairchem-core version. 2.21.1 for a release, 2.21.1.dev50+gdfbfb7044 for a dev checkout, so it pins a released install that has no commit.

Trained from	commit	branch	version
A dev checkout	core:db9b17fc6,experimental:NA	main	2.21.1.dev50+gdfbfb7044
A released install	core:None,experimental:NA	None	2.21.1

Both fields are Optional[str] = None, so existing configs and anything reading Metadata are unaffected.

One caveat worth knowing: for an editable install the version is resolved when the package is installed, so its embedded hash can lag behind metadata.commit. commit remains the accurate one.

Motivation

Makes a checkpoint's provenance self-describing: given a trained model you can tell exactly which fairchem code produced it, including for models trained from a PyPI install where no commit is recoverable today. Downstream checkpoint tooling can then surface it rather than asking the person who trained the model.

Test plan

New tests in tests/core/common/test_utils_.py cover get_branch_for_repo on a branch, on a detached HEAD, and outside a git repo, plus get_package_version.