Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.42.1 → 2.47.1 no changes
- 2.42.0 08/21/23
- 2.29.1 → 2.41.2 no changes
- 2.29.0 10/19/20
- 2.28.1 no changes
- 2.28.0 07/27/20
- 2.19.1 → 2.27.1 no changes
- 2.19.0 09/10/18
- 2.7.6 → 2.18.5 no changes
- 2.6.7 05/05/17
- 2.1.4 → 2.5.6 no changes
- 2.0.5 12/17/14
DESCRIPTION
Read the .idx
file for a Git packfile (created with
git-pack-objects[1] or git-index-pack[1]) from the
standard input, and dump its contents. The output consists of one object
per line, with each line containing two or three space-separated
columns:
-
the first column is the offset in bytes of the object within the corresponding packfile
-
the second column is the object id of the object
-
if the index version is 2 or higher, the third column contains the CRC32 of the object data
The objects are output in the order in which they are found in the index file, which should be (in a correctly constructed file) sorted by object id.
Note that you can get more information on a packfile by calling git-verify-pack[1]. However, as this command considers only the index file itself, it’s both faster and more flexible.
OPTIONS
- --object-format=<hash-algorithm>
-
Specify the given object format (hash algorithm) for the index file. The valid values are sha1 and (if enabled) sha256. The default is the algorithm for the current repository (set by
extensions.objectFormat
), or sha1 if no value is set or outside a repository..Note: At present, there is no interoperability between SHA-256 repositories and SHA-1 repositories.
Historically, we warned that SHA-256 repositories may later need backward incompatible changes when we introduce such interoperability features. Today, we only expect compatible changes. Furthermore, if such changes prove to be necessary, it can be expected that SHA-256 repositories created with today’s Git will be usable by future versions of Git without data loss.
GIT
Part of the git[1] suite