Refresh Git's Dumb HTTP Metadata with update-server-info

git update-server-info refreshes the two files that let dumb HTTP clients discover a repository on a server that cannot generate pack data on demand. It touches metadata only, never commits, branches or configuration.

Allow about ten minutes. You need Git and a readable repository directory. The examples use Git 2.43.0, the version installed here, from the git-man package. The installed manual and current upstream manual describe the same interface: one optional flag, -f or --force.

Checkpoint: this is an administrative command for the repository being published. It normally needs no elevated privileges when you own that repository. Use sudo only if the repository is deliberately owned by another account, and check the path before doing so.

1. Check the Git version and repository path

First confirm the program and the directory you intend to update. A bare repository is the common layout for a static or dumb HTTP export, but the command also works on a non-bare repository when Git can identify its Git directory.

$ git --version
git version 2.43.0
$ test -d /srv/git/project.git && test -d /srv/git/project.git/objects && echo "repository path looks plausible"
repository path looks plausible

Replace /srv/git/project.git with the exact path on your host. That second command is only a basic sanity check: it does not prove the directory holds a complete or healthy repository. Do not point it at a parent directory, a working copy you did not mean to publish, or a backup whose files are still being written.

2. Generate the auxiliary files

Run the command with Git's directory selected explicitly:

$ git --git-dir=/srv/git/project.git update-server-info

A successful run is normally silent and returns status 0. Capture the status immediately if you are checking it by hand:

$ git --git-dir=/srv/git/project.git update-server-info
$ printf 'exit status: %s\n' "$?"
exit status: 0

There is no progress report to wait for. Silence is not failure, but it also does not prove a web server can read the files or that the repository is reachable over HTTP.

3. Check what changed

The command updates two paths inside the repository's Git directory:

Inspect their existence without editing them:

$ ls -l /srv/git/project.git/objects/info/packs /srv/git/project.git/info/refs
$ sed -n '1,12p' /srv/git/project.git/objects/info/packs
$ sed -n '1,12p' /srv/git/project.git/info/refs

An empty bare repository can produce empty files, because it has no advertised refs or pack entries yet: that is different from a missing file. On a repository with refs, info/refs holds reference information, and the exact lines depend on the repository. Never hand-edit either file to add a branch or pack; re-run the command instead whenever the repository's published refs or pack layout changes.

4. Use force only when rebuilding from scratch

The optional flag tells Git to rebuild the info files from scratch:

$ git --git-dir=/srv/git/project.git update-server-info --force

-f is equivalent:

$ git --git-dir=/srv/git/project.git update-server-info -f

Safety boundary: the flag changes the generated metadata files only. It does not repair a corrupt object database, create a missing branch, or make a repository public. Because it rebuilds the files, do not treat it as a substitute for checking that the repository path and ownership are correct.

There is no separate undo operation. The files are derived from repository state, so the practical recovery is running the command again against the correct repository. Updated the wrong one by accident? Stop serving that directory and restore its metadata from your normal backup, or regenerate it once you have confirmed the correct path. Do not delete refs or objects as an attempted fix.

5. Diagnose the common failures

Git reporting that it cannot find a repository? Check the path and whether the directory is bare. Running the command from inside the repository is often clearer:

$ cd /srv/git/project.git
$ git update-server-info
$ printf 'exit status: %s\n' "$?"
exit status: 0

A permission error means inspecting ownership and mode as the account that serves or maintains the repository:

$ namei -l /srv/git/project.git/info/refs
$ id

Fix ownership through your normal service administration process. Do not make the repository world-writable, and do not reach for elevated privileges merely because the command is silent. A successful metadata refresh cannot compensate for a web server that exposes the wrong directory, blocks info/refs or objects/info/packs, or serves stale copies from a cache.

If clients still cannot clone, test the published URLs with the same account and network path those clients use. Check the web server's document root, access rules and logs separately: git update-server-info only generates the auxiliary files, it does not configure HTTP serving and it does not perform the client clone.

Done means