Git gains pluggable object storage, starting with relocatable files

Git is gaining a configurable object storage layer, parallel to the existing ref storage extension, so repositories can choose how and where objects live instead of always assuming the classic on-disk layout under .git/objects.

Patrick Steinhardt posted the work on the Git development list. A new extensions.objectStorage setting takes a schema and optional payload (files or files://path). For now only the familiar files backend is supported: loose objects and packfiles. The payload can point objects at another directory, relative to the common dir or absolute, so a repo can keep blobs and trees somewhere other than the default objects path without changing how Git talks to that store.

The same knobs already used for ref backends show up here: GIT_OBJECT_STORAGE_FORMAT, init.defaultObjectStorageFormat, and --object-storage-format= on init, clone, and submodule setup. Inspection hooks land on git rev-parse and git repo so scripts can read the active format. Local clones still require the files backend on both sides, because they hardlink object files; otherwise Git falls back to a normal clone or refuses an explicit local request.

Little user-visible behavior changes yet. The point is infrastructure: a stable extension and URI shape so later backends can plug in without another one-off config design. Review feedback from Karthik Nayak covered naming tension between object.format (hash algorithm) and objects.storageFormat, default handling, and path edge cases; a revised round keeps the repository’s storage format always populated and defers broader renames.