Просмотр содержимого объекта в Git - git cat-file

Введение

Когда вы работаете с Git, вы обычно видите только "поверхность" — коммиты, ветки, файлы в рабочем каталоге. Но внутри репозитория Git хранит всё в виде объектов (коммиты, деревья, блобы, теги). Иногда нужно заглянуть "под капот" и посмотреть, как именно Git представляет эти объекты. Для этого и существует команда git cat-file.

Смотрите, я покажу вам, как с помощью git cat-file:

• просматривать содержимое файлов (blob-объектов), как они реально хранятся в объектном хранилище;
• исследовать структуру дерева (tree) — какие файлы и каталоги входят в коммит;
• анализировать метаданные коммитов (commit-объектов) и тегов (tag-объектов);
• проверять целостность объектов и разбирать "сломанные" репозитории;
• строить свои небольшие "инструменты поверх Git", если нужно автоматизировать анализ истории.

Команда git cat-file не нужна в повседневной работе с Git, но она незаменима, если вы хотите глубже понимать, как Git устроен внутри, или отлаживаете какие-то нестандартные ситуации.

Теперь давайте разбираться по шагам.

Обзор команды git cat-file

Что делает git cat-file

Команда git cat-file позволяет:

• вывести содержимое объекта;
• вывести только заголовок (тип и размер);
• вывести объект в машинно-читаемом виде;
• работать в пакетном режиме для множества объектов.

Важно: git cat-file работает с объектами по их SHA-1 / SHA-256 хешу или по любому "именованному" указателю, который Git может разрешить (ветка, тег, HEAD, сокращённый хеш и т. д.).

Простейший синтаксис выглядит так:

git cat-file <опции> <объект>

Например:

# Показать содержимое объекта как текст
git cat-file -p <hash>

# Показать только тип объекта
git cat-file -t <hash>

# Показать размер объекта в байтах
git cat-file -s <hash>

Какие типы объектов есть в Git

Перед тем как смотреть примеры, давайте коротко напомним, какие вообще есть типы объектов. Это важно, потому что git cat-file управляет выводом в зависимости от типа.

В стандартной конфигурации Git хранит 4 базовых типа объектов:

• blob — содержимое файла (без имени и пути);
• tree — снимок каталога (список файлов и вложенных каталогов и ссылки на соответствующие blob и tree);
• commit — коммит, который указывает на корневое дерево (tree) и содержит метаданные (автор, сообщение, родители);
• tag — аннотированный тег в виде отдельного объекта, который указывает на другой объект (обычно commit).

У каждого объекта есть:

• тип (blob, tree, commit, tag),
• длина содержимого,
• само содержимое.

git cat-file как раз даёт вам возможность всё это увидеть.

Где вообще лежат эти объекты

Гит хранит объекты в каталоге .git/objects. В самом простом (расупакованном) виде объект лежит в виде файла:

• первые два символа хеша — имя подкаталога;
• остальные символы хеша — имя файла.

Например, объект с хешем a1b2c3d4... будет лежать в .git/objects/a1/b2c3d4....

Но вручную туда обычно не смотрят. Гораздо удобнее использовать git cat-file, потому что он:

• автоматически распаковывает объекты;
• корректно показывает кодировку и структуру;
• умеет работать с упакованными объектами (pack-файлы).

Теперь давайте перейдём к конкретным режимам работы.

Основные режимы git cat-file

Режим "pretty print": git cat-file -p

Опция -p (или --pretty) — самый удобный режим, если вы просто хотите "красиво" посмотреть содержимое объекта.

Синтаксис:

git cat-file -p <объект>

Git сам определяет тип объекта и выводит его в человеко-читаемом виде.

Давайте разберём по типам.

Просмотр commit-объекта

Попробуйте выполнить:

# HEAD — это указатель на последний коммит текущей ветки
git cat-file -p HEAD

Пример вывода:

tree 1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9
parent 9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a
author John Doe <john@example.com> 1733300000 +0300
committer John Doe <john@example.com> 1733300000 +0300

Initial commit

Комментарии к полям:

• tree … — ссылка на корневой объект дерева, описывающего файлы в этом коммите;
• parent … — ссылка на родительский коммит (может быть несколько строк parent, если это merge-коммит);
• author — кто и когда написал изменения;
• committer — кто и когда зафиксировал коммит в репозитории (может отличаться от автора при rebase, cherry-pick и т. д.);
• пустая строка;
• тело сообщения коммита.

Смотрите, я показываю вам то же, что вы обычно видите через git show, но без диффов, только "сырой" объект.

Вы можете указать не только HEAD, но и конкретный хеш:

git cat-file -p 1f2a7d3

Git автоматически дополнит сокращённый хеш до полного, если он однозначен.

Просмотр tree-объекта

Теперь давайте посмотрим, как выглядит дерево, на которое ссылается commit:

# Сначала посмотрим commit
git cat-file -p HEAD

# Скопируйте значение после 'tree ' и подставьте сюда
git cat-file -p 1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9

Вывод может выглядеть так:

100644 blob 3b18e92b2fc9f1ce46d9c88e2e5f1d48a1b2c3d4    main.go
100644 blob 7e3b649c1a9fe6a02af6315b4ef8b7d1c2d3e4f5    README.md
040000 tree 5a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b    internal

Как читается каждая строка:

• первые цифры — права доступа (POSIX режим файла, 100644 — обычный файл, 100755 — исполняемый файл, 040000 — каталог);
• далее тип объекта: blob или tree;
• затем хеш объекта;
• далее имя элемента (файла или каталога).

Здесь вы видите "структуру каталога" этого коммита. Если вы возьмёте хеш после tree и снова вызовете git cat-file -p, вы увидите содержимое подкаталога.

Просмотр blob-объекта

Чтобы увидеть реальное содержимое файла, найдите его blob:

# Скопируйте из вывода tree хеш для README.md
git cat-file -p 7e3b649c1a9fe6a02af6315b4ef8b7d1c2d3e4f5

Git выведет просто содержимое файла без заголовков. Как видите, это тот же текст, который вы открываете в рабочем каталоге.

Важно: blob не содержит ни имени файла, ни пути. Имя и путь задаются только на уровне дерева (tree). Это ключевая часть модели Git.

Просмотр tag-объекта

Если в репозитории есть аннотированные теги, вы можете посмотреть их как объекты:

git cat-file -p v1.0.0

Пример вывода:

object 1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9
type commit
tag v1.0.0
tagger John Doe <john@example.com> 1733301000 +0300

Release version 1.0.0

Здесь:

• object — хеш объекта, на который указывает тег (обычно commit);
• type — тип этого объекта;
• tag — имя тега;
• tagger — кто и когда создал тег;
• далее — сообщение тега.

Опять же, это "сырой вид" тега, который git show тоже может показывать, но с диффами.

Вывод типа и размера: -t и -s

Иногда вам не нужно содержимое, а только тип или размер. Тогда вы можете использовать:

# Посмотреть тип объекта
git cat-file -t <объект>

# Посмотреть размер объекта в байтах
git cat-file -s <объект>

Например:

git cat-file -t HEAD
# Вывод:
# commit

git cat-file -s HEAD
# Вывод:
# 217

Эти команды удобны, если вы пишете скрипты и хотите понять, с чем имеете дело и сколько это занимает.

Режим "raw": без опции -p

Когда вы запускаете:

git cat-file <тип> <объект>

она выводит "сырое содержимое", без форматирования. Но вам нужно явно указать ожидаемый тип объекта.

Пример:

git cat-file blob 7e3b649c1a9fe6a02af6315b4ef8b7d1c2d3e4f5

Это будет то же, что и git cat-file -p для blob. Но если вы укажете неверный тип — будет ошибка.

С коммитом это менее удобно:

git cat-file commit HEAD

Вы увидите содержимое со всеми заголовками так же, как и в режиме -p (для commit и tag результат почти совпадает). Главное отличие "raw" режима — он используется в пакетном режиме и в сценариях, где вы хотите строго контролировать тип.

Ссылки на объекты: как указывать <объект>

Команда git cat-file принимает любой идентификатор, который Git умеет "разрешить" в объект.

Давайте посмотрим, какие варианты вы можете использовать.

Полные и сокращённые хеши

Самая прямая форма:

git cat-file -p 1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9

Вы также можете использовать сокращённый хеш, если он однозначен:

git cat-file -p 1f2a7d3

Git сам найдёт объект, хеш которого начинается с этих символов, при условии, что такого объекта только один. Если в истории много объектов и префикс неоднозначен, Git сообщит об ошибке.

Имена веток, теги, HEAD

Чаще всего удобнее использовать:

git cat-file -p HEAD       # последний коммит текущей ветки
git cat-file -p main       # последний коммит ветки main
git cat-file -p feature-x  # последний коммит ветки feature-x
git cat-file -p v1.0.0     # объект, на который указывает тег v1.0.0

Git сам определит, на какой объект указывает указатель, и уже его передаст в cat-file.

Синтаксис ссылок: ^, ~, : и другие

Здесь git cat-file полностью использует механизм "rev-parse" Git. Вот несколько полезных примеров.

# Родитель HEAD
git cat-file -p HEAD^

# Второй родитель merge-коммита (если это merge)
git cat-file -p HEAD^2

# Прадед коммита (родитель родителя родителя)
git cat-file -p HEAD~3

Синтаксис с двоеточием удобен для доступа к файлам и деревьям:

# Посмотреть содержимое файла README.md в коммите HEAD
git cat-file -p HEAD:README.md

# Посмотреть содержимое подкаталога internal как tree-объект
git cat-file -p HEAD:internal

Обратите внимание: HEAD:README.md — это удобный способ обойтись без ручного поиска blob через дерево. Git сам:

1. берёт коммит HEAD;
2. находит его корневое дерево;
3. спускается по пути README.md;
4. берёт соответствующий blob-объект;
5. передаёт его git cat-file.

Вы можете использовать и более глубокие пути:

git cat-file -p HEAD:internal/service/user.go

Такие выражения особенно полезны, когда вы анализируете состояние конкретного файла в произвольном коммите.

Пакетный режим: git cat-file --batch и --batch-check

Когда нужно обработать много объектов (например, проанализировать весь pack-файл или вычислить размеры десятков blob), запускать git cat-file по одному объекту неэффективно. Для этого есть пакетный режим.

Общая идея пакетного режима

В пакетном режиме git cat-file:

• читает список объектов из стандартного ввода;
• построчно обрабатывает их;
• выводит результат в стандартный вывод.

Вам не нужно указывать объект в командной строке — вы просто передаёте его "потоком" из stdin.

--batch-check: вывести только заголовки

Режим --batch-check выводит основную информацию об объектах — без содержимого.

Синтаксис:

git cat-file --batch-check

Давайте разберёмся на примере. Сначала получим список каких-нибудь объектов:

# Получаем первые несколько объектов из списка известных Git хешей
git rev-list --objects --all | head -5

Пример вывода:

1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9
3b18e92b2fc9f1ce46d9c88e2e5f1d48a1b2c3d4 README.md
7e3b649c1a9fe6a02af6315b4ef8b7d1c2d3e4f5 main.go
...

Теперь вы можете передать только хеши в пакетный режим:

# Здесь мы используем cut чтобы взять только первый столбец с хешами
git rev-list --objects --all \
  | head -5 \
  | cut -d' ' -f1 \
  | git cat-file --batch-check

Пример вывода:

1f2a7d3f4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9 commit 217
3b18e92b2fc9f1ce46d9c88e2e5f1d48a1b2c3d4 blob 1234
7e3b649c1a9fe6a02af6315b4ef8b7d1c2d3e4f5 blob 567
...

Формат по умолчанию:

<hash> <type> <size>

Комментарии:

• hash — полный SHA-1 (или SHA-256, если ваш репозиторий так настроен);
• type — тип объекта (blob, tree, commit, tag);
• size — размер содержимого объекта в байтах.

Кастомизированный формат для batch-check

С помощью опции --batch-check='формат' вы можете задать свой формат вывода, похожий на формат для git for-each-ref.

Пример:

# Выводим тип и размер разделённые табуляцией
git rev-list --objects --all \
  | head -5 \
  | cut -d' ' -f1 \
  | git cat-file --batch-check='%(objecttype) %(objectsize) %(rest)'

Здесь:

• %(objecttype) — тип объекта;
• %(objectsize) — размер;
• %(rest) — "остаток" строки, который был передан в stdin (например, имя файла после хеша, если вы не отрезали его через cut).

Это очень удобно, если вы строите отчёты по размерам файлов или хотите быстро найти самые "тяжёлые" blob в репозитории.

--batch: заголовок + содержимое

Режим --batch идёт дальше — кроме заголовка, он печатает и содержимое каждого объекта.

Синтаксис:

git cat-file --batch

Git ожидает, что вы будете построчно кормить ему идентификаторы объектов. Например:

# Здесь мы явно передаём два объекта в stdin
printf "HEAD\nHEAD^{tree}\n" | git cat-file --batch

Вывод будет в виде:

<hash> <type> <size>
<raw content bytes...>
<hash> <type> <size>
<raw content bytes...>
...

Важно понимать:

• содержимое объекта может содержать любые байты (включая нулевые, переводы строк и т. д.);
• между объектами нет пустых строк — следующий заголовок начинается сразу после окончания содержимого предыдущего объекта.

Поэтому анализ такого вывода удобнее делать программой, которая:

• читает строку до перевода строки — это заголовок;
• парсит размер;
• считывает из потока указанное количество байт как содержимое.

Здесь я размещаю простой пример на Bash, чтобы вам было проще понять:

# Здесь мы получаем несколько blob из истории и печатаем первые 40 байт каждого
git rev-list --objects --all \
  | head -3 \
  | cut -d' ' -f1 \
  | git cat-file --batch \
  | while read header; do
      # header содержит строку вида "<hash> <type> <size>"
      set -- $header              # Разбиваем строку по пробелам
      hash=$1                     # Хеш объекта
      type=$2                     # Тип объекта
      size=$3                     # Размер содержимого

      echo "Объект $hash типа $type размером $size байт"

      # Читаем первые 40 байт содержимого и выводим их
      head -c 40

      # Остальную часть содержимого нужно "пропустить"
      # size-40 байт мы прочитаем и выбросим
      rest=$((size - 40))
      if [ "$rest" -gt 0 ]; then
        head -c "$rest" > /dev/null
      fi
    done

Комментарии к коду:

• while read header; do — читает заголовок каждого объекта;
• head -c 40 — читает первые 40 байт;
• затем мы явно "съедаем" оставшиеся байты, чтобы корректно перейти к заголовку следующего объекта.

Этот пример показывает, как важно в пакетном режиме учитывать, что содержимое не разделено спецсимволами.

Использование пакетного режима из других языков

Если вы пишете анализатор на Python, Go или другом языке, подход примерно такой же:

• запускаете git cat-file --batch как подпроцесс;
• пишете в его stdin хеши или имена объектов;
• читаете stdout построчно + заданное число байт.

Покажу вам короткий пример на Python, который обходит несколько объектов и выводит первые байты их содержимого:

import subprocess

# Запускаем git cat-file в пакетном режиме
proc = subprocess.Popen(
    ["git", "cat-file", "--batch"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    text=False  # Важно - работаем с байтами
)

# Список объектов для запроса
objects = [b"HEAD\n", b"HEAD^{tree}\n"]

# Отправляем запросы
for obj in objects:
    proc.stdin.write(obj)
proc.stdin.flush()

for _ in objects:
    # Читаем заголовок
    header = proc.stdout.readline()  # байты до \n
    # Преобразуем заголовок в строку для разбора
    header_str = header.decode("utf-8").strip()
    obj_hash, obj_type, obj_size = header_str.split()
    size = int(obj_size)

    print("Объект", obj_hash, "тип", obj_type, "размер", size)

    # Читаем содержимое объекта
    content = proc.stdout.read(size)
    # Здесь мы выводим только первые 60 байт
    print("Первые байты содержимого:", content[:60])

# Завершаем подпроцесс
proc.stdin.close()
proc.wait()

Комментарии:

// Мы запускаем git cat-file --batch и обмениваемся с ним данными через stdin/stdout
// Важно использовать text=False чтобы не ломать бинарные объекты
// Для каждого объекта сначала читаем строку заголовка а затем ровно size байт содержимого

Такой подход даёт вам готовый "API" для работы с хранилищем Git поверх командной строки.

Практические сценарии использования git cat-file

Теперь давайте посмотрим, как git cat-file помогает решать реальные задачи.

Проверка содержимого конкретного файла в старом коммите

Частая ситуация: вы хотите понять, как выглядел файл в определённом коммите, но не хотите переключаться туда git checkout.

Здесь самый простой путь:

git cat-file -p <commit>:<путь/к/файлу>

Примеры:

# Как выглядел README.md в коммите a1b2c3d
git cat-file -p a1b2c3d:README.md

# Как выглядел internal/user.go во вчерашнем HEAD~1
git cat-file -p HEAD~1:internal/user.go

Это удобно, если вы пишете скрипт сравнения файлов между коммитами или хотите быстро "вытащить" старую версию файла.

Анализ структуры дерева и поиск нужного blob

Иногда вам нужно вручную пройти путь от коммита до конкретного blob. Это полезно, если вы хотите лучше понять модель Git.

Давайте разберёмся на примере шаг за шагом:

# 1. Смотрим commit
git cat-file -p HEAD

# Предположим, видим:
# tree 1f2a7d3...

# 2. Смотрим дерево
git cat-file -p 1f2a7d3...

# Предположим, видим строку:
# 040000 tree 5a7b8c9d...    internal

# 3. Заходим в подкаталог internal
git cat-file -p 5a7b8c9d...

# Предположим, видим:
# 100644 blob 7e3b649c...    user.go

# 4. И наконец смотрим содержимое файла
git cat-file -p 7e3b649c...

Так вы руками повторяете то, что Git делает автоматически при разрешении выражения HEAD:internal/user.go.

Поиск самого большого файла в репозитории

Задача: выяснить, какие файлы (blob) занимают больше всего места в истории.

Смотрите, как это можно сделать с помощью git cat-file и нескольких команд оболочки:

# Шаг 1 - получаем все объекты вместе с именами файлов
git rev-list --objects --all \
  | git cat-file --batch-check='%(objectname) %(objecttype) %(objectsize) %(rest)' \
  | awk '$2 == "blob" {print $0}' \
  | sort -k3 -n \
  | tail -10

Комментарии:

// git rev-list --objects --all выдает список всех объектов с хешом и путем до файла если это blob
// git cat-file --batch-check дополняет каждую строку типом и размером объекта
// awk '$2 == "blob"' оставляет только строки где тип объекта blob
// sort -k3 -n сортирует по третьему полю то есть по размеру по возрастанию
// tail -10 выводит 10 самых больших файлов

Так вы можете быстро найти "тяжёлые" файлы, которые, возможно, стоит вынести из истории или заигнорировать.

Исследование повреждённого репозитория

Иногда Git жалуется на "bad object", "missing blob" и похожие ошибки. git cat-file помогает локализовать проблему.

Например, если git fsck говорит вам, что объект с определённым хешем повреждён, вы можете попробовать:

git cat-file -t <hash>   # Проверить тип, если объект существует
git cat-file -p <hash>   # Попробовать вывести содержимое

Если объект отсутствует (например, его удалили вручную из .git/objects или pack-файл повреждён), вы увидите сообщение об ошибке.

Далее можно:

• проверить, есть ли этот объект в .git/objects (если он был распакован);
• проверить pack-файлы (каталог .git/objects/pack);
• попытаться восстановить репозиторий из удалённого (если это clone и всё ещё есть origin).

git cat-file здесь играет роль "низкоуровневого" инструмента проверки.

Понимание отличий между git show и git cat-file

Многие команды Git под капотом используют git cat-file. Например, git show для коммита фактически выводит:

• содержимое commit-объекта (похоже на git cat-file -p);
• плюс дифф между этим коммитом и его родителем;
• плюс декорации вроде имени ветки, тега и т. д.

Иногда для обучения полезно сделать так:

# Сначала посмотреть "сырые" данные:
git cat-file -p HEAD

# А затем привычный вывод:
git show HEAD

Так вы увидите, как Git строит свой "user-friendly" интерфейс поверх очень простой модели: коммит → дерево → блобы.

Дополнительные опции и нюансы

Вывод в виде хекса: --batch-all-objects и --buffer (современные версии)

В новых версиях Git есть дополнительные опции, вроде --batch-all-objects, которые заставляют git cat-file работать сразу со всеми объектами, известными репозиторию. Но чаще для этого достаточно комбинаций rev-list и batch-check.

Например:

# Обойти все объекты включая недостижимые и внутренние
git cat-file --batch-all-objects --batch-check

Эта команда полезна, если вы хотите исследовать вообще всё, что лежит в объектном хранилище, включая объекты, на которые уже нет ссылок в ветках и тегах.

Кодировка и бинарные файлы

git cat-file сам по себе не знает, является ли blob текстом или бинарным файлом. Он просто печатает байты.

Когда вы делаете:

git cat-file -p <blob>

Git просто пишет содержимое в stdout. Если это бинарный файл (например, изображение), терминал может отреагировать некорректно (покажет "кракозябры" или даже "подвесит" вывод).

Чтобы избежать этого:

• используйте перенаправление в файл:

  git cat-file -p <blob> > output.bin
  

• или ограничивайте количество выводимых байт (например, через head -c).

Отличия SHA-1 и SHA-256 репозиториев

В новых версиях Git (при специальной настройке) можно использовать SHA-256 вместо SHA-1. Для git cat-file это почти прозрачно:

• длина хеша становится больше (64 символа вместо 40 для SHA-1);
• но сама логика работы не меняется;
• все команды, которые вы видели, работают одинаково.

Единственное, что может отличаться — формат pack-файлов и взаимодействие с другими инструментами, но для простого анализа объектов git cat-file это несущественно.

---

git cat-file — это инструмент, который помогает посмотреть, как Git реально хранит данные: коммиты, деревья, блобы и теги. С его помощью вы можете:

• изучить структуру репозитория на низком уровне;
• понимать, как связаны между собой коммиты и файлы;
• писать скрипты анализа истории и размеров;
• отлаживать проблемные ситуации, связанные с повреждёнными объектами.

Если вы уверенно пользуетесь git log, git show и git diff, следующий шаг — время от времени заглядывать в объекты через git cat-file и связывать "высокоуровневое" представление с внутренней моделью Git. Это делает работу с системой контроля версий значительно понятнее.

Частозадаваемые технические вопросы по теме и ответы

Как с помощью git cat-file понять, к какому коммиту относится конкретный blob

Непосредственно по blob-объекту Git не хранит обратную ссылку на коммит. Но вы можете найти все деревья и коммиты, которые содержат этот blob.

Мини-инструкция:

# 1. Находим все деревья которые указывают на этот blob
git rev-list --all --objects \
  | grep <blob_hash>

# 2. Опционально ищем коммиты где этот файл фигурирует в деревьях
git log --all --find-object=<blob_hash>

Команда --find-object работает в новых версиях Git и показывает все коммиты, в чьём дереве присутствует этот blob.

Как вывести содержимое объекта без завершающего перевода строки

git cat-file сам по себе печатает то, что хранится в объекте. Если вам нужно убрать завершающий перевод строки в выводе blob, используйте инструменты оболочки:

git cat-file -p <blob_hash> | perl -pe 'chomp if eof'

Здесь мы удаляем только последний перевод строки в конце потока.

Как узнать сразу и тип и размер объекта одной командой без batch-режима

Используйте опцию -e, чтобы проверить существование, и комбинацию -t и -s:

obj=<hash_or_ref>

git cat-file -e "$obj" 2>/dev/null && {
  type=$(git cat-file -t "$obj")
  size=$(git cat-file -s "$obj")
  echo "$obj $type $size"
}

Это удобно, если вы не хотите включать пакетный режим, но вам нужно всё-таки немного автоматизации.

Как вывести "сырая" форма tree-объекта в виде байтов

Формат вывода git cat-file -p для tree уже отличается от "сырых байтов". Чтобы увидеть реальное бинарное содержимое дерева, используйте:

git cat-file tree <tree_hash> > raw_tree.bin

Здесь мы указываем тип tree явно и перенаправляем результат в файл. В raw_tree.bin будет ровно то, что хранится в объекте, без преобразований.

Как посмотреть объект по offset в pack-файле через git cat-file

Напрямую по смещению в pack-файле git cat-file работать не умеет. Но если у вас есть хеш объекта, вы можете:

git cat-file -p <hash>

Если нужно именно смещение, можно использовать git verify-pack:

git verify-pack -v .git/objects/pack/pack-*.idx | grep <hash>

Вывод покажет смещение объекта в pack-файле, тип и размер. Затем уже по хешу вы используете git cat-file для просмотра содержимого.