Fetch a Commit from a Dumb HTTP Git Repository

You will use git http-fetch to download a commit and its reachable objects from an HTTP-served Git repository, optionally record the commit in a local ref, and check that the object arrived. This is a plumbing command for the older HTTP fetch protocol. It is not the normal command for a modern Git remote.

Allow about fifteen minutes. You need Git and an HTTP or HTTPS URL that serves the repository in the layout expected by this command. The examples use Git 2.43.0 from the installed git-man package, version 1:2.43.0-1ubuntu7.3. No step needs elevated privileges if your local Git directory is writable.

1. Confirm the installed command

Check the binary and its synopsis before preparing a destination:

$ git --version
git version 2.43.0
$ git http-fetch -h
usage: git http-fetch [-c] [-t] [-a] [-v] [--recover] [-w ref] [--stdin | --packfile=hash | commit-id] url

The manpage calls the command git-http-fetch, but the installed interface is normally invoked as git http-fetch. The command writes into the current repository's object database, so run it from the destination repository or set GIT_DIR explicitly.

Checkpoint: git --version should identify the Git release you intend to use. If git http-fetch is missing, stop and install the Git package through your normal system administration process. Do not copy an internal helper from another machine.

2. Prepare an empty destination

Create a separate destination for a first test. This changes the new directory, not an existing project:

$ mkdir git-http-fetch-test
$ cd git-http-fetch-test
$ git init
Initialized empty Git repository in /path/to/git-http-fetch-test/.git/

If you already have a repository intended to receive the objects, use that repository instead and omit git init. Check where Git will store them:

$ git rev-parse --git-dir
.git

The output can be an absolute path, especially for a worktree or a repository supplied through GIT_DIR. You need write access there. There is no reason to use sudo, and running this as root can leave root-owned objects that your normal account cannot maintain.

3. Choose a commit and a trusted URL

Obtain the exact commit ID from the repository owner or from a trusted catalogue. The command accepts either a commit hash or a filename under the remote URL's refs/ directory. The URL must expose the old HTTP Git files, not merely a web page containing a repository link.

Use HTTPS where it is available. A hash is still worth checking against an independent trusted value: HTTPS protects the connection, while the commit ID tells you which object graph you requested. Do not paste credentials into a URL or fetch from an untrusted server into a repository that contains valuable work.

$ REMOTE_URL='https://git.example.invalid/project.git/'
$ REMOTE_COMMIT='0123456789abcdef0123456789abcdef01234567'
$ test "\${REMOTE_URL#https://}" != "$REMOTE_URL"
$ test "\${#REMOTE_COMMIT}" -eq 40

These assignments are placeholders. Replace both values with real, verified values before running the fetch. The final slash is a useful convention for a repository URL because the command fetches paths below it.

4. Fetch the commit and report transfers

Run the fetch with -v when you want diagnostics about what is downloaded:

$ git http-fetch -v "$REMOTE_COMMIT" "$REMOTE_URL"
$ printf 'exit status: %s\n' "$?"
exit status: 0

A zero status means the command completed successfully. The verbose lines are transfer diagnostics, so their exact wording and ordering are not a stable interface. The command always downloads all objects in the reachable object graph; the historical -a, -c and -t switches do not narrow that set and are silently ignored.

Verify the requested object in the destination:

$ git cat-file -t "$REMOTE_COMMIT"
commit
$ git fsck --no-reflogs --no-progress "$REMOTE_COMMIT"
Verifying connectivity: ... done.

The git fsck wording varies by Git release. The useful result is that cat-file identifies the object as a commit and fsck does not report a missing reachable object.

5. Record the fetched commit in a ref

Use -w during the fetch when another tool needs a named local ref. Its argument is a ref filename below $GIT_DIR/refs/:

$ git http-fetch -v -w fetched "$REMOTE_COMMIT" "$REMOTE_URL"
$ git rev-parse refs/fetched
0123456789abcdef0123456789abcdef01234567

Replace the displayed hash with your real commit ID. The ref is local state, so choose a name that will not collide with an existing ref. Before allowing a command to replace an existing name, inspect it:

$ git show-ref refs/fetched
0123456789abcdef0123456789abcdef01234567 refs/fetched

To undo this named-ref change, delete only that ref:

$ git update-ref -d refs/fetched

This does not immediately delete downloaded objects. That is deliberate: other refs may need them, and Git's later housekeeping decides when unreachable objects can be pruned.

6. Recover an interrupted transfer

If an earlier fetch was interrupted, rerun it with --recover and the same target:

$ git http-fetch -v --recover -w fetched "$REMOTE_COMMIT" "$REMOTE_URL"
$ git cat-file -e "$REMOTE_COMMIT^{commit}"
$ printf 'exit status: %s\n' "$?"
exit status: 0

--recover verifies that everything reachable from the target is present. It is a repair check after an interrupted fetch, not a way to make an unreliable or untrusted URL safe. If it fails, preserve the diagnostic output, check the URL and commit ID, and investigate disk space and write permission before retrying.

7. Keep internal modes out of normal scripts

--stdin reads lines containing a commit ID, optionally followed by a tab and the filename used with -w. The --packfile and --index-pack-args options are marked for internal use and are not ordinary repository-fetch interfaces. Do not build a deployment workflow around them unless you are implementing the Git machinery that calls them and have tested the exact Git release.