When a service, environment, or infrastructure is stored remotely in Git, Harness records a fallback branch that it uses to load the entity's YAML if the configured branch can't be resolved. This fallback branch is set automatically based on whichever branch was active when the entity was first created or moved to remote storage.

The problem is that there's currently no supported way to update this value after the fact. If an entity was created or imported while a user was on a feature branch, that feature branch stays recorded as the fallback indefinitely, even long after it's been merged or deleted.

The update-git-metadata API lets us update the connector, repo name, and file path, but not the fallback branch, and there's no UI control for it either.

This matters most for production entities, where a stale fallback branch could mean Harness loading configuration from a branch that no longer reflects current state. Teams running governance or audit reviews can identify the problem but have no clean way to remediate it.

The only current workaround is to move the entity from remote back to inline and then back to remote again while the desired branch is active, which is disruptive and not practical at scale across many entities.

We'd like a supported way to update the fallback branch directly, ideally as an additional field on the existing update-git-metadata endpoints (and surfaced in the UI alongside the other Git metadata settings), so teams can audit and correct the fallback branch without moving entities in and out of remote storage.

Use case: A governance review flags that several production environments have a fallback branch pointing to an old, merged feature branch. We want to reset these to main in place, without disrupting the entities or re-importing them.