Git cat file: Git - git-cat-file Documentation

Содержание

Работа непосредственно с объектами git

Цели

Исследовать структуру базы данных объектов
Научиться использовать SHA1 хэши для поиска содержимого в репозитории

Давайте исследуем объекты git с помощью некоторых инструментов.

01 Поиск последнего коммита

Выполните:

git hist --max-count=1

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

Результат:

$ git hist --max-count=1
* 8029c07 2011-03-09 | Added index.html. (HEAD, master) [Alexander Shvets]

02 Вывод последнего коммита

С помощью SHA1 хэша из коммита, указанного выше…

Выполните:

git cat-file -t <hash>
git cat-file -p <hash>

Вот что выходит у меня…

Результат:

$ git cat-file -t 8029c07
commit
$ git cat-file -p 8029c07
tree 096b74c56bfc6b40e754fc0725b8c70b2038b91e
parent 567948ac55daa723807c0c16e34c76797efbcbed
author Alexander Shvets <alex@githowto. com> 1299684476 -0500
committer Alexander Shvets <[email protected]> 1299684476 -0500

Added index.html.

Примечание: Если вы задали алиасы «type» и «dump», как описано в уроке об алиасах, можете вводить команды git type и git dump вместо длинных команд (которые я никогда не запоминаю).

Это вывод объекта коммита, который находится во главе ветки master.

03 Поиск дерева

Мы можем вывести дерево каталогов, ссылка на который идет в коммите. Это должно быть описание файлов (верхнего уровня) в нашем проекте (для конкретного коммита). Используйте SHA1 хэш из строки «дерева», из списка выше.

Выполните:

git cat-file -p <treehash>

Вот как выглядит мое дерево…

Результат:

$ git cat-file -p 096b74c
100644 blob 28e0e9d6ea7e25f35ec64a43f569b550e8386f90    index.html
040000 tree e46f374f5b36c6f02fb3e9e922b79044f754d795    lib

Да, я вижу index. html и каталог lib.

04 Вывод каталога lib

Выполните:

git cat-file -p <libhash>

Результат:

$ git cat-file -p e46f374
100644 blob c45f26b6fdc7db6ba779fc4c385d9d24fc12cf72    hello.html

Существует файл hello.html.

05 Вывод файла hello.html

Выполните:

git cat-file -p <hellohash>

Результат:

$ git cat-file -p c45f26b
<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
  </head>
  <body>
    <h2>Hello, World!</h2>
  </body>
</html>

А вот и он. Мы вывели объекты коммитов, объекты деревьев и объекты блобов непосредственно из репозитория git. Это все, что есть – блобы, деревья и коммиты.

06 Исследуйте самостоятельно

Исследуйте git репозиторий вручную самостоятельно. Смотрите, удастся ли вам найти оригинальный файл hello.html с самого первого коммита вручную по ссылкам SHA1 хэша в последнем коммите. к параметру ревизии означает первого родителя этого объекта фиксации(коммита)….

чтобы прочитать содержимое (или blob-объект ) объекта git

git cat-file -p <SHA1>

чтобы прочитать его тип

git cat-file -t <SHA1>

Поделиться

Matoeil

29 мая 2017 в 13:42

Хотя cat действительно означает «concatenate»,, на самом деле он просто отображает один или несколько файлов в порядке их появления в аргументах командной строки до cat . Общим шаблоном для просмотра содержимого файла в системах Linux или *nix является:

cat <file>

Основное различие между cat и Git cat-file заключается в том, что он отображает только один файл (следовательно, часть -file ). Git cat-file на самом деле не означает «concatenate»;, это просто ссылка на поведение команды cat .

git-cat-file -предоставление информации о содержании или типе и размере объектов репозитория

Технически вы можете использовать git cat-file для объединения файлов, если используете режим пакетного вывода:

ПАКЕТНЫЙ ВЫВОД
Если задано --batch или --batch-check , то cat-file будет считывать объекты из stdin, по одному на строку, и печатать информацию о них. По умолчанию вся строка рассматривается как объект, как если бы она была передана в git-rev-parse [1].

Поделиться

Will

04 июля 2016 в 04:51

добавить к ответу @Matoeil,
Вам нужно только указать 5 символов вашего <SHA1> .

$ tree .git/

.git/
├── COMMIT_EDITMSG
├── HEAD
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           ├── master
│           └── testBranch
├── objects
│   ├── 1e
│   │   └── e2a78c0b40dd8e5c6b08e31171a3ce1e8d931b
│   ├── 29
│   │   └── 33b9017f79a27ff5ad3c4e154f67b44ae8482c
│   ├── 4a
│   │   └── 6a376085b9b3b8e6e73d2cdcc5281cf6915c58
│   ├── 4b
│   │   └── 825dc642cb6eb9a060e54bf8d69288fbee4904
│   ├── 7e
│   │   └── 6965a8b2ff07da3e632a24ee024b9d2ec5245d
│   ├── ae
│   │   └── 853f7ece778281c463c1f0c603ef9d47a425b7
│   ├── info
│   └── pack
└── refs
├── heads
│   ├── master
│   └── testBranch
└── tags

17 directories, 28 files

$ git cat-file -t ae853
tree 

$ git cat-file -p ae853
100644 blob 7e6965a8b2ff07da3e632a24ee024b9d2ec5245d    fil1. txt

вот объясните очень хорошо.

Поделиться

roottraveller

19 августа 2019 в 07:16

Почему cat 0>file не работает
В Unix я знаю, что 0 1 и 2 представляют собой stdin stdout и stderr. Насколько я понимаю, команда cat , означающая concatenate, может объединять разные файлы. Например, cat file>&1 может объединить file и stdout, а стрелка означает перенаправление с file на stdout, поэтому мы можем видеть…
Подмодуль фиксирует объект ‘недопустимое имя объекта’ при использовании ‘git cat-file-p’
Я немного больше ознакомился с git внутренними элементами и различными git объектами. У меня есть простой репозиторий с одним файлом .txt в верхнем каталоге, двумя файлами .txt (file1.txt и file2.txt) в каталоге под названием ‘my-directory’ и подмодулем под названием ‘my-submodule’. Я получаю…

Как распечатать старую версию файла Git LFS в stdout (git show / git cat-file for LFS)?

Другим названием этого вопроса может быть «как проверить несколько версий управляемого файла Git-LFS?».

Я хотел бы проверить несколько версий файла, хранящегося в Git-LFS. Поэтому я хотел бы иметь несколько версий этого файла side-by-side в моем рабочем каталоге. Что-то вроде этого я имею в виду:

git show v1:./myfile.ipynb > myfile-v1.ipynb
git show v2:./myfile.ipynb > myfile-v2.ipynb

Это работает не так, как хотелось бы: файл управляется Git-LFS, поэтому до git show его содержимое в каждой версии выглядит так

version https://git-lfs.github.com/spec/v1
oid sha256:62aafe00ec8b61a37dd729e7d3a723382...
size 20439

Меня интересует содержимое файла ‘true’, Git-LFS-managed, а не файл указателя, который LFS хранит в собственном дереве Git.

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

git

git-lfs

Поделиться

Источник

Esteis

08 июня 2018 в 12:34

3 ответа

Поддерживает ли Git-Extensions git lfs?
Я не смог найти никакой информации на эту тему. Поскольку Git-Extensions использует в основном (или это: только) командную строку для работы с репозиторием, я предполагаю, что она должна быть OK с git lfs. Diff, Blaming, File-History и т. д. не должны быть проблемой, так как lfs будет обрабатывать…
Не удается извлечь файл с Git LFS: «неизвестная команда «post-checkout» для «git-lfs»`
Когда я выполняю следующую команду, находясь в ветке функций: git checkout origin/master foo.js Я получаю следующую ошибку: $ git checkout origin/master foo.js Error: unknown command post-checkout for git-lfs Run ‘git-lfs —help’ for usage. Почему это происходит и как мне исправить эту проблему?…

Передача указателя lfs в git lfs smudge даст вам то, что вы хотите. Например:

git cat-file blob <blob-sha> | git lfs smudge

Или если у вас есть commit-ish (commit hash, имя ветви, просто HEAD и т. д.) И имя файла:

git cat-file blob <commit-ish>:path/to/my-large-file.name | git lfs smudge

Вы можете перенаправить вывод в файл.

Поделиться

markonius

06 февраля 2019 в 07:18

Обновление: @Markonius’ ответ -это правильный способ сделать это.

Вот сценарий, который делает это на основе экспериментов с репозиторием LFS. Я не рассматривал протокол LFS в деталях, так что могли быть неучтенные причуды, но это сработало для моего простого случая.

git-lfs-cat-file

Соответствующие детали таковы:

LFS файлы хранятся в индексе со следующей структурой:
```
version https://git-lfs.github.com/spec/v1
oid sha256:abcdeffffffffffffff
size nnnnnnnn
```
Фактический объект LFS тогда будет находиться под .git/lfs/objects/ab/cd/abcdeffffffffffffff .

Поделиться

Koterpillar

06 февраля 2019 в 04:15

Когда я в последний раз работал с LFS, на странице проекта велись разговоры о лучшей интеграции — например, о написании diff и/или инструментов слияния, которые можно было бы подключить через .gitattributes . Они, по-видимому, не считались высокоприоритетными, поскольку основной предполагаемый вариант использования LFS-защита больших двоичных файлов (но, конечно, я сталкивался с несколькими случаями, когда либо у меня был большой текстовый файл, либо единственный разумный способ настроить правила отслеживания LFS бросал достаточно широкую сеть, чтобы поймать несколько небольших текстовых файлов). Я не уверен, что был какой-то прогресс в этих инструментах, так как я уже давно не заглядывал на страницу проекта.

В отсутствие этих вещей нет особенно «slick» способа сделать то, о чем вы просите. Вы можете настроить два рабочих дерева и проверить различные версии. Вы можете проверить одну версию, переименовать ее, а затем проверить другую.

Поделиться

Mark Adelsberger

08 июня 2018 в 12:41

Какой git-lfs использует `git lfs`?
Я только что обновил свой установленный Git LFS с https://github.com/git-lfs/git-lfs/releases до последней версии (2.3.0). Однако, когда я запускаю git lfs version , я вижу: $ git lfs version git-lfs/2.2.1 (GitHub; windows amd64; go 1.8.3; git 621d1f82) Если я запускаю git-lfs version , то вижу…
Git LFS пропускает файл, но git начинает толкать его в репо
У меня есть большой файл в моем репо Github, который я обычно загружал с git lfs. Для более новой фиксации(коммита) мне пришлось изменить файл, но теперь при нажатии git lfs пропускает файл, и обычный git пытается загрузить его. Это, конечно, не удается, потому что он превышает максимальный размер. ..

Основные GIT Команды

Введение

Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды.

Все тарифы хостинга от Hostinger включают интеграцию с Github, что позволяет легко публиковать сайты на хостинге непосредственно с репозитория!

К тарифам

Что вам понадобится

Перед тем, как вы начнете это руководство, вам понадобится следующее:

GIT установленный на вашей системе

Основные GIT команды

Одна из самых часто используемых git команд. Она может быть использована для указания пользовательских настроек, таких как электронная почта, имя пользователя, формат и т.д. К примеру, данная команда используется для установки адреса электронной почты:

git config --global user. email адрес@gmail.com

Эта команда используется для создания GIT репозитория. Пример использования:

git init

Команда git add может быть использована для добавления файлов в индекс. К примеру, следующая команда добавит файл под названием temp.txt присутствующий в локальном каталоге в индекс:

git add temp.txt

Команда git clone используется для клонирования репозитория. Если репозиторий находится на удаленном сервере, используется команда такого рода:

git clone имя.пользователя@хост:/путь/до/репозитория

И наоборот, для клонирования локального репозитория используйте:

git clone /путь/до/репозитория

Команда git commit используется для коммита изменений в файлах проекта. Обратите внимание, что коммиты не сразу попадают на удаленный репозиторий. Применение:

git commit –m “Сообщение идущее вместе с коммитом”

Команда git status отображает список измененных файлов, вместе с файлами, которые еще не были добавлены в индекс или ожидают коммита. Применение:

git status

git push еще одна из часто используемых git команд. Позволяет поместить изменения в главную ветку удаленного хранилища связанного с рабочим каталогом. Например:

git push origin master

Команда git checkout может быть использована для создания веток или переключения между ними. К примеру, следующий код создаст новую ветку и переключится на нее:

command git checkout -b <имя-ветки>

Чтобы просто переключиться между ветками используйте:

git checkout <имя-ветки>

Команда позволяет пользователю подключиться к удаленному репозиторию. Данная команда отобразит список удаленных репозиториев, настроенных в данный момент:

git remote –v

Эта команда позволит пользователю подключить локальный репозиторий к удаленному серверу:

git remote add origin <адрес.удаленного.сервера>

Команда git branch может быть использована для отображения, создания или удаления веток. Для отображения всех существующих веток в репозитории введите:

git branch

Для удаления ветки:

git branch –d <имя-ветки>

Команда pull используется для объединения изменений, присутствующих в удаленном репозитории, в локальный рабочий каталог. Применение:

git pull

Команда git merge используется для объединения ветки в активную ветвь. Применение:

git merge <имя-ветки>

Команда git diff используется для выявления различий между ветками. Для выявления различий с базовыми файлами, используйте

git diff --base <имя-файла>

Следующая команда используется для просмотра различий между ветками, которые должны быть объединены, до их объединения:

git diff <ветвь-источник> <ветвь-цель>

Для простого отображения существующих различий, используйте:

git diff

Используется для маркировки определенных коммитов с помощью простых меток. Примером может быть эта команда:

git tag 1. 1.0 <вставьте-commitID-здесь>

Запуск команды git log отобразит список всех коммитов в ветке вместе с соответствующими сведениями. Пример результата:

commit 15f4b6c44b3c8344caasdac9e4be13246e21sadw
Author: Alex Hunter <[email protected]>
Date:   Mon Oct 1 12:56:29 2016 -0600

Команда git reset используется для сброса индекса и рабочего каталога до последнего состояния коммита. Применение:

git reset --hard HEAD

git rm используется для удаления файлов из индекса и рабочего каталога. Применение:

git rm имяфайла.txt

Возможно одна из самых малоизвестных команд git. Она помогает в сохранении изменений на временной основе, эти изменения не попадут в коммит сразу. Применение:

git stash

Для просмотра информации о любом git объекте используйте команду git show. Для примера:

git show

git fetch позволяет пользователю доставить все объекты из удаленного репозитория, которые не присутствуют в локальном рабочем каталоге. Пример применения:

git fetch origin

Команда git ls-tree используется для просмотра дерева объекта вместе с названием, режимом каждого предмета и значением SHA-1. К примеру:

git ls-tree HEAD

Используйте команду git cat-file, чтобы просмотреть тип объекта с помощью SHA-1 значения. Например:

git cat-file –p d670460b4b4aece5915caf5c68d12f560a9fe3e4

git grep позволяет пользователю проводить поиск фраз и слов в содержимом деревьев. К примеру, для поиска www.hostinger.ru во всех файлах используйте эту команду:

git grep "www.hostinger.ru"

gitk — это графический интерфейс локального репозитория. Вызвать его можно выполнив данную команду:

gitk

С помощью команды git instaweb можно запустить веб-сервер, связанный с локальным репозиторием. Браузер также автоматически будет перенаправляться на него. Например:

git instaweb –httpd=webrick

Для оптимизации репозитория используйте команду git gc. Она поможет удалить и оптимизировать ненужные файлы:

git gc

Команда git archive позволяет пользователю создать .zip или .tar файл содержащий компоненты одного из деревьев репозитория. Например:

git archive --format=tar master

С помощью команды git prune удаляются объекты, не имеющие никаких входящих указателей. Применение:

git prune

Чтобы выполнить проверку целостности файловой системы git, используйте команду git fsck, при этом будут идентифицированы все поврежденные объекты:

git fsck

Команда git rebase используется для применения коммитов в другой ветке. Например:

git rebase master

Заключение

В данном руководстве вы узнали основные GIT команды и познакомились с примерами их использования. Обязательно посетите наше руководство об основах GIT для ознакомления с его настройкой и использованием.

Git: «Поврежденный свободный объект»

Я только что испытал это — моя машина разбилась во время записи в репозиторий Git, и она стала поврежденной. Я исправил это следующим образом.

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

gitk &

Если вы не используете этот инструмент, он очень удобен — насколько мне известно, он доступен во всех операционных системах. Это указывало на то, что на моем пульте не было двух коммитов. Поэтому я нажал на метку, указывающую последний удаленный коммит (обычно это будет /remotes/origin/master), чтобы получить хеш (хеш длиной 40 символов, но для краткости я здесь использую 10 — это обычно работает в любом случае).

Вот:

14c0fcc9b3

Затем я нажимаю на следующий коммит (т. Е. Первый, который удаленный не имеет) и получаю хэш:

04d44c3298

Затем я использую оба из них, чтобы сделать патч для этого коммита:

git diff 14c0fcc9b3 04d44c3298 > 1. patch

Затем я сделал то же самое с другим отсутствующим коммитом, то есть использовал хэш коммита до и сам хэш коммита:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Затем я переехал в новый каталог, клонировал репозиторий с пульта:

git clone [email protected]:username/repo.git

Затем я переместил файлы исправлений в новую папку, применил их и зафиксировал их с точными сообщениями фиксации (их можно вставить из окна git logили из gitkокна):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Это восстановило вещи для меня (и заметьте, что, вероятно, есть более быстрый способ сделать это для большого количества коммитов). Однако мне было интересно посмотреть, можно ли отремонтировать дерево в поврежденном репо, и ответ — можно. С восстановленным репо, доступным, как указано выше, выполните эту команду в сломанной папке:

git fsck

Вы получите что-то вроде этого:

error: object file . git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Чтобы сделать ремонт, я бы сделал это в сломанной папке:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

т.е. удалите поврежденный файл и замените его на хороший. Возможно, вам придется сделать это несколько раз. Наконец-то наступит момент, когда вы сможетеfsck без ошибок. Вероятно, в отчете будут строки «висячий коммит» и «висячий блоб», это следствие ваших перебазировок и исправлений в этой папке, и все в порядке. Сборщик мусора удалит их со временем.

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

Git — git-cat-file — Name git-cat-файл-Предоставление контента или информации о типе и размере объект

В своей первой форме команда предоставляет содержимое или тип объекта в репозитории. Тип является обязательным, если для поиска типа объекта не используется -t или -p , или -s используется для определения размера объекта, или используется --textconv или --filters (что подразумевает тип «blob»).

Во второй форме список объектов (разделенных переводом строки) предоставляется на stdin, а SHA-1, тип и размер каждого объекта печатаются на stdout. Формат вывода можно переопределить с помощью необязательного аргумента <format> . Если --textconv или --filters , ожидается, что на входе будут перечислены имена объектов, за которыми следует имя пути, разделенные одним пробелом, чтобы можно было определить соответствующие драйверы.

Если указан -t , один из <тип>.

Если указан -s , размер <объекта> в байтах.

Если указан -e , вывод не будет, если <объект> не имеет неправильного формата.

Если указан параметр -p , содержимое <object> печатается красиво.

Если указан <type>, будет возвращено необработанное (хотя и несжатое) содержимое <object>.

Если --batch или --batch-check , cat-file будет читать объекты из стандартного ввода, по одному в строке, и печатать информацию о них. По умолчанию вся строка рассматривается как объект, как если бы она была передана в git-rev-parse [1] .

Вы можете указать информацию, отображаемую для каждого объекта, с помощью настраиваемого <format> . <format> копируется буквально на стандартный вывод для каждого объекта, с заполнителями вида %(atom) расширенной, с последующим переводом строки. Доступные атомы:

objectname: Имя объекта размером в 40 гексов.
objecttype: Тип объекта (то же, что и cat-file -t reports).
objectsize: Размер объекта в байтах (такой же, как у отчетов cat-file -s ).
objectsize:disk: Размер в байтах, который объект занимает на диске. См. Примечание о размерах на диске в разделе CAVEATS ниже.
deltabase: Если объект хранится как дельта на диске, он расширяется до 40-шестнадцатеричного sha1 базового дельта-объекта. В противном случае расширяется до нулевого sha1 (40 нулей). См. CAVEATS ниже.
rest: Если этот атом используется в выходной строке, входные строки разделяются по первой границе пробела. Все символы перед этим пробелом считаются именем объекта; символы после этого первого пробела (т.е. «остальная часть» строки) выводятся вместо атома %(rest) .

Если формат не указан, по умолчанию используется формат %(objectname) %(objecttype) %(objectsize) .

Если --batch , за информацией об объекте следует содержимое объекта (состоящее из байтов %(objectsize) ), за которым следует новая строка .

Например, --batch без специального формата выдаст:

<sha1> SP <type> SP <size> LF
<contents> LF

В то время как --batch-check='%(objectname) %(objecttype)' выдаст:

Если в stdin указано имя, которое не может быть преобразовано в объект в репозитории, то cat-file проигнорирует любой пользовательский формат и напечатает:

Если указано имя, которое может относиться к более чем одному объекту (неоднозначное короткое sha), то cat-file проигнорирует любой настраиваемый формат и напечатает:

Если используется —follow-symlinks, а символическая ссылка в репозитории указывает за пределы репозитория, то cat-file проигнорирует любой пользовательский формат и напечатает:

symlink SP <size> LF
<symlink> LF

Символическая ссылка будет либо абсолютной (начиная с /), либо относительно корня дерева. Например, если dir / link указывает на . ./../foo, тогда <symlink> будет ../foo. <размер> — размер символической ссылки в байтах.

При использовании —follow-symlinks будут отображены следующие сообщения об ошибках:

распечатывается,когда запрошенная начальная сим-ссылка не существует.

dangling SP <size> LF
<object> LF

печатается,когда существует исходная сим-ссылка,но то,на что она указывает (переходный из),не печатается.

loop SP <size> LF
<object> LF

распечатывается для циклов симлинков (или любых симлинков,для разрешения которых требуется более 40 разрешений ссылок).

notdir SP <size> LF
<object> LF

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

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

Также обратите внимание, что в базе данных объектов может быть несколько копий объекта; в этом случае не определено, какой размер копии или дельта-база будет сообщаться.

Что скрывает от нас директория .git / Хабр

Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

Вот так выглядит .git после команды git init.

Это не все, что вы можете увидеть, так как при дальнейшей работе появятся другие файлы и директории. Например, так выглядит . git на моем рабочем проекте.

Я не буду описывать назначение каждого файла, а остановлюсь на основных моментах.

Самыми важными элементами являются objects, refs, HEAD, index. Для того чтобы понять, что это и с чем их едят, мы создадим несколько файлов, каталог, и добавим их в наш репозиторий.

Объекты

Первоначально каталог оbjects содержит пустые подкаталоги pack и info и никаких файлов.

Создадим в рабочей директории файл test.txt с содержимым «test file version 1».

$ echo ‘test file version 1’ > test.txt

Добавим этот файл в индекс.

$ git add test.txt

Теперь посмотрим что изменилось у нас в репозитории.

$ find .git/objects
.git/objects/27/703ec79a98c1d097d5b1cd320befffa376e826

В директорию objects добавился файл. Следует сказать, что все файлы в данной директории являются git объектами определенного типа.
Давайте посмотрим содержимое и тип данного объекта с помощью команды cat-file.

$ git cat-file -p 2770
test file version 1
$ git cat-file -t 2770
blob

Данный объект имеет тип blob. Это и есть начальное представление данных в Git — один файл на единицу хранения с именем, которое вычисляется как SHA1 хеш содержимого и заголовка объекта. Первые два символа SHA определяют подкаталог файла, остальные 38 — имя. Данный объект просто хранит снимок содержимого файла test.txt.

Далее видим, что появился файл index. Это бинарный файл, содержащий список индексированных файлов и связанных с ними blob объектов.

$ git ls-files --stage
100644 27703ec79a98c1d097d5b1cd320befffa376e826 0       test.txt

То есть индекс содержит всю необходимую информацию для создания tree объекта при последующем коммите. Tree объект — это еще один тип объекта в git. Чуть позже мы с ним познакомимся.
А теперь добавим каталог new и файл new/new.txt

$ mkdir new
$ echo "new file" > new/new.txt
$ git add .
$ find .git/objects -type f
. git/objects/27/703ec79a98c1d097d5b1cd320befffa376e826
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92

Давайте узнаем тип нового объекта и его содержимое.

$ git cat-file -p fa49
new file
$ git cat-file -t fa49
blob

И заглянем снова в index.

$ git ls-files --stage
100644 fa49b077972391ad58037050f2a75f74e3671e92 0       new/new.txt
100644 27703ec79a98c1d097d5b1cd320befffa376e826  0       test.txt

А теперь все это закоммитим.

$ git commit -m "first commit"
[master (root-commit) cae1990] first commit
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 new/new.txt
create mode 100644 test.txt

Теперь наш репозиторий содержит 5 объектов.

$ find .git/objects -type f
.git/objects/27/703ec79a98c1d097d5b1cd320befffa376e826
.git/objects/49/66bf4e5c88c5f9d149b45bb2f3099644701d93
.git/objects/ca/e19909974ee9e64f5787fe4ee89b9b8fe94ccf
.git/objects/eb/85079ce7fd354ffc630f4a8e2991196cb3807f
. git/objects/fa/49b077972391ad58037050f2a75f74e3671e92

Добавилось еще три файла. Посмотрим что это за файлы.

$ git cat-file -t 4966
tree
$ git cat-file -p 4966
040000 tree eb85079ce7fd354ffc630f4a8e2991196cb3807f    new
100644 blob 27703ec79a98c1d097d5b1cd320befffa376e826    test.txt

$ git cat-file -t eb85
tree
$ git cat-file -p eb85
100644 blob fa49b077972391ad58037050f2a75f74e3671e92    new.txt

Это другой тип объектов git — tree объект. Объект данного типа содержит одну или более записей, указывающей на другое дерево или на blob объект.
И наконец, последний тип объекта — объект-коммит.

$ git cat-file -p cae1
tree 4966bf4e5c88c5f9d149b45bb2f3099644701d93
author Ivan Ivanov <[email protected]> 1335783964 +0300
committer Ivan Ivanov <[email protected]> 1335783964 +0300

first commit

Мы видим дерево верхнего уровня, о котором я уже упоминал ранее, имя автора и коммитера и сообщение коммита.
Сделаем новое изменение(в test. txt изменим текст на «test file version 2»)и закоммитим. Кроме ссылки на дерево появилась еще ссылка на предшествующий коммит.

$ git cat-file -p b303
tree 42e998096f18d4249dc00ec89eaaadc44a8bf3cb
parent cae19909974ee9e64f5787fe4ee89b9b8fe94ccf
author Ivan Ivanov <[email protected]> 1335786789 +0300
committer Ivan Ivanov <[email protected]> 1335786789 +0300

second commit

Чтобы все стало на свои места, нарисуем граф объектов

Ссылки

В git ссылка — это файл-указатель с простым именем, который содержит значение хеша SHA-1. Данные файлы размещаются в каталоге .git/refs/

$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/heads/master
.git/refs/tags

Так как у нас только одна ветка master, то и ссылка тоже только одна, которая указывает на последний коммит.
Давайте сделаем бранч release, указывающий на первый коммит.

$ git branch release cae1990

$ find .git/refs
.git/refs
.git/refs/heads
. git/refs/heads/master
.git/refs/heads/release
.git/refs/tags

$ cat .git/refs/heads/release
cae19909974ee9e64f5787fe4ee89b9b8fe94ccfa

Вот по сути что такое ветка в git — простой указатель на определенный коммит.
Посмотрим более наглядно

HEAD

Данный файл содержит ссылку не на хеш, а на текущую ветку.

$ cat .git/HEAD
ref: refs/heads/master

Если перейти на другую ветку, то и содержание данного файла изменится.

$ git co release
Switched to branch 'release'

$ cat .git/HEAD
ref: refs/heads/release

Вместо итога

А есть еще метки, удаленные ссылки, директория info и много много вкусного.

Git — git-cat-file Документация

Если задано --batch или --batch-check , cat-file будет читать объекты
из стандартного ввода, по одному в строке, и вывести информацию о них. По умолчанию,
вся строка рассматривается как объект, как если бы она была передана в
git-rev-parse [1].

Вы можете указать информацию, отображаемую для каждого объекта, используя настраиваемый
<формат> . буквально копируется в стандартный вывод для каждого
объект с заполнителями вида % (атом) развернут, за которым следует
новая линия.Доступные атомы:

имя объекта: Полное шестнадцатеричное представление имени объекта.
тип объекта: Тип объекта (аналогично cat-file -t reports).
Размер объекта: Размер объекта в байтах (то же, что и cat-file -s
отчеты).
размер объекта: диск: Размер в байтах, занимаемый объектом на диске.Увидеть
обратите внимание на размеры на диске в разделе CAVEATS ниже.
deltabase: Если объект хранится как дельта на диске, он расширяется до
полное шестнадцатеричное представление имени дельта-базового объекта.
В противном случае расширяется до нулевого OID (все нули). См. ПЕЩЕРА
ниже.
остальное: Если этот атом используется в выходной строке, входные строки разделяются
на первой границе пробела.Все персонажи до этого
пробелы считаются именем объекта; символы
после этого первого пробела (т. е. «остальная часть»
строка) выводятся вместо % (остального) атома .

Если формат не указан, по умолчанию используется формат % (имя объекта). % (тип объекта)% (размер объекта).

Если указано --batch , за информацией об объекте следует
содержимое объекта (состоящее из % (размер объекта) байта), за которым следует
новая линия.

Например, --batch без специального формата даст:

  SP <тип> SP <размер> LF
<содержание> LF

Тогда как --batch-check = '% (objectname)% (objecttype)' даст:

Если на stdin указано имя, которое не может быть преобразовано в объект в
репозиторий, то cat-file проигнорирует любой пользовательский формат и напечатает:

Если используется --follow-symlinks , а символическая ссылка в репозитории указывает
вне репозитория, то cat-file проигнорирует любой пользовательский формат
и распечатать:

 символическая ссылка SP <размер> LF
 LF

Символьная ссылка будет либо абсолютной (начиная с /), либо относительной.
к корню дерева.Например, если dir / link указывает на ../../foo , то
будет ../foo . <размер> — размер символической ссылки в байтах.

Если используется --follow-symlinks , будут отображаться следующие сообщения об ошибках.
отображается:

печатается, когда запрошенная начальная символическая ссылка не существует.

 dangling SP <размер> LF
<объект> LF

печатается, когда существует начальная символическая ссылка, но что-то, что
он (transitive-of) указывает на нет.

 петля SP <размер> LF
<объект> LF

печатается для циклов символических ссылок (или любых символических ссылок,
требуется более 40 разрешений ссылок для разрешения).

 notdir SP <размер> LF
<объект> LF

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

Git — git-cat-file Документация

имя объекта: Имя объекта из 40 шестнадцатеричных чисел.
тип объекта: Тип объекта (аналог cat-file -t reports).
Размер объекта: Размер объекта в байтах (то же, что и cat-file -s
отчеты).
размер объекта: диск: Размер в байтах, занимаемый объектом на диске. Увидеть
обратите внимание на размеры на диске в разделе CAVEATS ниже.
deltabase: Если объект хранится как дельта на диске, он расширяется до
40-шестнадцатеричный sha1 базового объекта дельты. В противном случае расширяется до
null sha1 (40 нулей). См. CAVEATS ниже.
остальное: Если этот атом используется в выходной строке, входные строки разделяются
на первой границе пробела. Все персонажи до этого
пробелы считаются именем объекта; символы
после этого первого пробела (т.е.е., «остальная часть»
строка) выводятся вместо % (остального) атома .

Если формат не указан, по умолчанию используется формат % (имя объекта). % (тип объекта)% (размер объекта).

Например, --batch без специального формата даст:

  SP <тип> SP <размер> LF
<содержание> LF

Тогда как --batch-check = '% (objectname)% (objecttype)' даст:

Если используется —follow-symlinks, а символическая ссылка в репозитории указывает
вне репозитория, то cat-file проигнорирует любой пользовательский формат
и распечатать:

 символическая ссылка SP <размер> LF
 LF

Символьная ссылка будет либо абсолютной (начинающейся с /), либо относительной.
к корню дерева.Например, если dir / link указывает на ../../foo, то
будет ../foo. <размер> — размер символической ссылки в байтах.

Если используется —follow-symlinks, будут отображаться следующие сообщения об ошибках.
отображается:

печатается, когда запрошенная начальная символическая ссылка не существует.

 dangling SP <размер> LF
<объект> LF

печатается, когда существует начальная символическая ссылка, но что-то, что
он (transitive-of) указывает на нет.

 петля SP <размер> LF
<объект> LF

печатается для циклов символических ссылок (или любых символических ссылок,
требуется более 40 разрешений ссылок для разрешения). символа

Хэш SHA1 данной ревизии

Первые несколько (возможно, 5) символов заданного хэша SHA1

Подсказка Важно помнить, что при использовании « git show » всегда указывает путь от корня репозитория , а не текущую позицию в каталоге.

(Хотя Майк Морарти упоминает, что, по крайней мере, с git 1.7.5.4, вы можете указать относительный путь, поместив « ./ » в начало пути.: ./ test.py

)

Использование

git restore

С Git 2.23+ (август 2019 г.) вы также можете использовать git restore , который заменяет сбивающую с толку команду git checkout

  git restore -s  - файл
git restore -s somebranch - файл

Это восстановит в рабочем дереве только файл, который присутствует в «исходном коде» ( -s ). зафиксирует SHA1 или ответвит somebranch .
Для восстановления также индекса:

  git restore -s  -SW - файл

( -SW : сокращенно от --staged --worktree )

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

До git1.5.x это было сделано с помощью сантехники:

git ls-tree
показать список одного или нескольких объектов blob в коммите

git cat-file blob
cat файл, зафиксированный в определенной ревизии (аналогично svn
Кот). используйте git ls-tree для получения значения данного файла-sha1

  git cat-file -p $ (git-ls-tree $ REV $ file | cut -d "" -f 3 | cut -f 1) ::

git-ls-tree перечисляет идентификатор объекта для $ file в ревизии $ REV , это вырезается из вывода и используется в качестве аргумента для git-cat-file , который действительно должен называться git-cat-object и просто выгружает этот объект в stdout .

Примечание: начиная с Git 2.11 (4 квартал 2016 г.), вы можете применить фильтр содержимого к выходным данным git cat-file .

См.
совершить 3214594,
совершить 7bcf341 (09 сен 2016),
совершить 7bcf341 (09 сентября 2016 г.) и
совершить b9e62f6,
commit 16dcc29 (24 августа 2016 г.), автор Johannes Schindelin ( dscho ).
^{(объединено Junio C Hamano — gitster — в фиксации 7889ed2, 21 сентября 2016 г. )}

  git config diff.txt.textconv "tr A-Za-z N-ZA-Mn-za-m <"
git cat-file --textconv --batch

Примечание: " git cat-file --textconv " недавно (2017) начал использовать segfaulting, что было исправлено в Git 2.15 (4 кв.2017 г.)

См. Коммит cc0ea7c (21 сентября 2017 г.) Джеффа Кинга ( peff ).
^{(объединено Junio C Hamano - gitster - в фиксации bfbc2fc, 28 сентября 2017 г.)}

msysgit - вывод файла git-cat - qaru

Я не уверен, что git cat-file --batch должен работать так, как вы упомянули в своем вопросе.
(возможно, после git 2.8, март 2016 г., см. Ниже)

Даже в "книге GitMagic" в среде unix используется git cat-file , как упоминается в комментариях:

Убедитесь, что этот файл действительно содержит вышеуказанное, набрав:

  $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch

Как ОП Алексей. Шен упоминает выше, это проблема новой строки : команды
git всегда будут ожидать LF ^{(Line Feed, U + 000A)}, а не Windows CRLF ^{( CR + LF : CR (U + 000D), за которым следует последовательность LF (U + 000A))}.
С « | ', он использует символ EOL оболочки bash msysgit ( LF ), поэтому он всегда работает.

Примечание: Git 2.5+ (второй квартал 2015 г.) добавит поддержку символических ссылок с помощью git cat-file --batch .
(Новые выпуски Git доступны для Windows по адресу github.com/git-for-windows/git/releases )

См. Фиксацию 122d534 Дэвида Тернера ( csusbdt ), 20 мая 2015 г.
^{(объединено Junio C Hamano - gitster - в фиксации 67f0b6f, 1 июня 2015 г.)}

cat-file : добавить --follow-symlinks с на --batch
« git cat-file --batch (-check) » изучил параметр « --follow-symlinks », который следует за символической ссылкой в дереве, когда его спрашивают о
объект через расширенный синтаксис SHA-1.
Например, HEAD: RelNotes , который указывает на Documentation / RelNotes / 2.5.0.txt .
С новым параметром команда ведет себя так, как если бы вместо этого в качестве входных данных было задано HEAD: Documentation / RelNotes / 2.5.0.txt .

Обновление, февраль 2016 г .:

Git 2.8 добавляет поддержку CRLF в некоторые команды git:

См. Фиксацию a551843, фиксацию 933bea9, фиксацию 1536dd9, фиксацию b42ca3d, фиксацию 692dfdf, фиксацию 3f16396, фиксацию 18814d0, фиксацию 1f3b1ef, фиксацию 72e37b6, фиксацию 6e8d46f, фиксацию c0353c7 (28 октября 2015 г.), автор: Junio C Hamano ().
^{(объединено Junio C Hamano - gitster - в фиксации 0175655, 3 февраля 2016 г.)}

В частности, commit b42ca3d использует strbuf.c # strbuf_getline () (который может принимать байт, отличный от LF или NUL в качестве признака конца строки)

С git 2. 8:

cat-file : чтение пакетного потока с помощью strbuf_getline ()
Можно подготовить текстовый файл с помощью редактора DOS и загрузить его
как пакетный поток команд к команде .

Manpage Ubuntu: git-cat-file - Предоставляет информацию о содержимом или типе и размере для объектов репозитория

Предоставлено: git-man_1.9.1-1_all

НАИМЕНОВАНИЕ

       git-cat-file - Предоставляет информацию о содержимом или типе и размере для объектов репозитория.

ОБЗОР

         git   cat-file  (-t | -s | -e | -p |  | --textconv) <объект>
         git   cat-file  (--batch | --batch-check) <<список-объектов>

ОПИСАНИЕ

       В своей первой форме команда предоставляет содержимое или тип объекта в
       репозиторий.Тип является обязательным, если только  -t  или  -p  не используются для поиска типа объекта или  -s . 
       используется для определения размера объекта, или используется  --textconv  (что подразумевает тип "blob").

       Во второй форме список объектов (разделенных переводом строки) предоставляется на stdin, и
       SHA-1, тип и размер каждого объекта выводятся на стандартный вывод.

ОПЦИИ

       <объект>
           Имя отображаемого объекта.Для более полного списка способов написания объекта
           имена, см. раздел «УКАЗАНИЕ ИЗМЕНЕНИЙ» в  gitrevisions  (7).

       -t
           Вместо содержимого покажите тип объекта, обозначенный

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Git cat file: Git — git-cat-file Documentation

Работа непосредственно с объектами git

Цели

Выполните:

Результат:

Выполните:

Результат:

Выполните:

Результат:

Выполните:

Результат:

Выполните:

Результат:

Похожие вопросы:

Как распечатать старую версию файла Git LFS в stdout (git show / git cat-file for LFS)?

3 ответа

Похожие вопросы:

Основные GIT Команды

Git: «Поврежденный свободный объект»

Git — git-cat-file — Name git-cat-файл-Предоставление контента или информации о типе и размере объект

Что скрывает от нас директория .git / Хабр

Объекты

Ссылки

HEAD

Вместо итога

Git — git-cat-file Документация

Git — git-cat-file Документация

Использование

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

msysgit - вывод файла git-cat - qaru

Manpage Ubuntu: git-cat-file - Предоставляет информацию о содержимом или типе и размере для объектов репозитория

cat-file (1) - справочная страница Linux

Имя

Сводка

Описание

Опции

Выход

Автор

Документация

Git

Банкноты

Сантехника - Учебник Ry’s Git

Проверить детали фиксации

Осмотрите дерево

Изучение большого двоичного объекта

Изучите метку

Проверить представление ветви Git

Изучение базы данных объектов

Собери мусор

Добавить файлы в индекс

Сохранение индекса в базе данных

Создание объекта фиксации

Обновление HEAD

Заключение

Краткий справочник

Добавить комментарий Отменить ответ

`Сохранение индекса в базе данных`

`Создание объекта фиксации`

`Обновление HEAD`

`Заключение`

`Краткий справочник`