Extract a Git Blob into a Temporary File

You will use git unpack-file to turn a Git blob object into a temporary file that you can read with ordinary tools. The repository, index and working-tree files remain unchanged. Allow about ten minutes. You need Git 2.43.0 or a compatible installation and a local repository containing the blob you want to inspect.

This guide follows the installed git-unpack-file(1) manual shipped by git-man version 1:2.43.0-1ubuntu7.3 on the reference system. The command has a deliberately small interface: it accepts one blob ID and prints the name of the file it created.

1. Confirm the Git version and repository

Start with read-only checks. You do not need sudo, and using elevated privileges can leave the extracted file owned by root in a directory you cannot easily tidy.

$ git --version
git version 2.43.0
$ git rev-parse --show-toplevel
/path/to/your/repository

Run the commands from inside the repository that contains the object. If the second command fails, change to a working tree or set GIT_DIR for a bare repository before continuing.

Checkpoint: you have a Git repository selected and your Git version is visible. The command is part of the normal Git suite, but it is a low-level object operation rather than a way to restore a named file automatically.

2. Resolve a path to its blob ID

The argument must identify a blob, not a commit, tree or tag. A revision followed by a colon is a convenient way to resolve a file from a commit. Replace COMMIT and path/to/file with values that exist in your repository:

$ COMMIT=HEAD
$ PATH_IN_COMMIT='path/to/file'
$ blob=$(git rev-parse "$COMMIT:$PATH_IN_COMMIT")
$ printf 'blob: %s\n' "$blob"
blob: 0123456789abcdef0123456789abcdef01234567
$ git cat-file -t "$blob"
blob

The displayed object ID is an example shape, not a value to paste. Git repositories can use different object formats, so keep the complete ID printed by your own command. If git rev-parse reports that the path does not exist, check the spelling and the commit. If git cat-file -t does not print blob, stop here: git unpack-file is not intended for that object type.

This step only resolves metadata. It does not check out the file, update the index or write to the working tree.

3. Extract the blob

Pass the verified object ID as one quoted argument. Store the command's standard output because that output is the name of the new file:

$ temporary_file=$(git unpack-file "$blob")
$ printf 'temporary file: %s\n' "$temporary_file"
temporary file: .merge_file_GB4wTq

The suffix is generated and will differ on every run. The documented filename format is .merge_file_<random-suffix>. The file is created in your current directory, not beside the original path, and its contents are the blob's contents without Git's path or commit metadata.

Do not redirect this command to another file unless you specifically want a second copy. Its useful result is the returned pathname. Keep the variable in the same shell session while you inspect the result.

Checkpoint: a pathname beginning with .merge_file_ was printed and the file exists. If the command reports that it cannot read the object, re-check the repository, object ID and object type. A guessed hash is not a useful diagnostic.

4. Inspect and compare the contents

Use read-only tools to check the extraction. The first command confirms that the file is present, the second shows its contents, and the third compares it with the source path in the selected commit:

$ test -f "$temporary_file" && echo 'temporary file exists'
temporary file exists
$ sed -n '1,20p' "$temporary_file"
first line from the blob
more content from the blob
$ git show "$COMMIT:$PATH_IN_COMMIT" | cmp -s - "$temporary_file"
$ printf 'comparison status: %s\n' "$?"
comparison status: 0

A comparison status of 0 means the extracted bytes match the selected commit's file. The sed output is only illustrative; binary blobs should not be treated as text. For a binary or large object, use cmp, file or a checksum instead of printing it:

$ file "$temporary_file"
$ sha256sum "$temporary_file"

Do not mistake a successful extraction for a checkout. Git has not changed the working-tree copy, and edits to the temporary file are not recorded as Git changes.

5. Remove the temporary file when finished

git unpack-file creates a file for you; it does not provide a cleanup command. Once you have finished inspecting it, remove exactly the pathname held in the variable:

$ rm -- "$temporary_file"
$ test ! -e "$temporary_file" && echo 'temporary file removed'
temporary file removed

Warning: rm is irreversible. Check the variable with printf '%s\n' "$temporary_file" before running it, especially if the variable came from an untrusted script. If you need the extracted data later, copy it to a deliberately named destination first and check that destination before removing the temporary file.

If your shell session ended before cleanup, look only in the repository directory you used and inspect candidate names before deleting anything. Do not use a broad wildcard such as rm .merge_file_* in a shared working directory, because another process may own one of those files.

6. Diagnose the common mistakes

A commit ID is not a blob ID. Passing HEAD directly asks Git to unpack a commit and fails because the command requires a blob. Resolve a file with git rev-parse COMMIT:path and verify it with git cat-file -t.

A path that exists in your working tree may not exist in the commit you selected. The colon expression reads the tree stored in that commit, so an uncommitted file cannot be resolved from HEAD. For a file staged in the index, use the appropriate index-aware lookup before passing its blob ID.

Names beginning with .merge_file_ are temporary artefacts, not restored working-tree paths. Rename or copy the result only after you have checked what it contains. No service restart, repository repair or elevated privilege is required for this workflow.