Problem
Use case:
An application creates and uses a repository entirely offline, then later lets the user promote that same repository to a server without changing its repository identity or replaying its history.
Current behavior:
repository config exposes get but no setter or attach operation. repository create and clone initialize new local repositories rather than attaching an existing one.
Proposed solution
Requested behavior:
Provide a supported command and C API operation that:
- accepts a remote URL for an existing local repository;
- optionally validates or registers the remote name with the local repository ID;
- atomically persists remote_url;
- rejects mismatched remote identities; and
- leaves the previous configuration unchanged on any failure.
Alternatives considered
The configuration reference permits editing .lore/config.toml by hand, and setting remote_url there works, but every embedding application must implement that mutation itself.
Problem
Use case:
An application creates and uses a repository entirely offline, then later lets the user promote that same repository to a server without changing its repository identity or replaying its history.
Current behavior:
repository config exposes get but no setter or attach operation. repository create and clone initialize new local repositories rather than attaching an existing one.
Proposed solution
Requested behavior:
Provide a supported command and C API operation that:
Alternatives considered
The configuration reference permits editing .lore/config.toml by hand, and setting remote_url there works, but every embedding application must implement that mutation itself.