Разное

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 <[email protected] 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 хэша в последнем коммите. к параметру ревизии означает первого родителя этого объекта фиксации(коммита)….



8

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

git cat-file -p <SHA1>

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

git cat-file -t <SHA1>

Поделиться


Matoeil    

29 мая 2017 в 13:42



6

Хотя 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



0

добавить к ответу @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-cat-file выход

Когда я запустил git cat-file —batch на коммите, он вывел отсутствует. {tree} , используемым для печати древовидного объекта, соответствующего ветви master (commit). Могу ли…

что означает git man pages [ <file-option> ]

Я читаю справочные страницы git-config , Вы тоже можете проверить это здесь. https://www.git-scm.com/docs/git-config/1.8.3 В синопсисе я не могу понять , что означает [<file-option>] , я…

Что означает — в файле cat —

Недавно мне пришлось использовать какой-то код, который мне дали, и в нем есть такая строка cat file — Может быть, кто-то знает, что означает — ?

Как распечатать старую версию файла 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. Почему это происходит и как мне исправить эту проблему?…



4

Передача указателя 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



2

Обновление: @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



0

Когда я в последний раз работал с 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 lfs с «normal» git

Я клонировал свой обычный (не LFS) репозиторий на локальный диск. Теперь я хочу добавить к нему файл размером более 100 МБ и зафиксировать изменение в репозитории. Для этого я использовал следующие…

Git lfs (Large File Storage) говорит, что управляемые файлы lfs изменяются после извлечения git lfs

У меня есть рабочая копия репозитория, который использует git-lfs для хранения некоторых больших файлов. У меня установлен двоичный файл git-lfs, но, возможно, он не запускал git lfs install внутри…

Ускорьте преобразование bash скрипта git repo в LFS

Я пытаюсь преобразовать репозиторий git в lfs. В данный момент я пробую этот сценарий bash и заметил, что он довольно медленный. Кто-нибудь знает, как это немного ускорить ? Я на самом деле не…

Поддерживает ли Git-Extensions git lfs?

Я не смог найти никакой информации на эту тему. Поскольку Git-Extensions использует в основном (или это: только) командную строку для работы с репозиторием, я предполагаю, что она должна быть OK с…

Не удается извлечь файл с Git LFS: «неизвестная команда «post-checkout» для «git-lfs»`

Когда я выполняю следующую команду, находясь в ветке функций: git checkout origin/master foo.js Я получаю следующую ошибку: $ git checkout origin/master foo.js Error: unknown command post-checkout…

Какой 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 пропускает файл, но git начинает толкать его в репо

У меня есть большой файл в моем репо Github, который я обычно загружал с git lfs. Для более новой фиксации(коммита) мне пришлось изменить файл, но теперь при нажатии git lfs пропускает файл, и. ..

Доступ к ссылке Git LFS? Git LFS ссылка заменяет файлы указателей на LFS

Мне нужно было сохранить двоичный файл размером 60 МБ с Git LFS. Ссылка работала в течение 6 дней, wget https://media.githubusercontent.com/media/raqueeb/datasets/master/bnwiki-texts.zip Теперь wget…

Версия одного файла в git-lfs

Есть ли способ настроить git-lfs для хранения только 1 версии отслеживаемого файла LFS? Новые версии файла должны заменить старые. В других работах старая фиксация(коммит) должна ссылаться на…

Удаление git-lfs

Как вы можете сделать полное удаление/unistall git-lfs, пожалуйста? Я сделал git lfs uninstall , который вернул следующие две строки: Hooks for this repository have been removed Global Git LFS…

Основные 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 проигнорирует любой пользовательский формат и напечатает:

Если указано имя, которое может относиться к более чем одному объекту (неоднозначное короткое sha), то 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 Документация

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

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

имя объекта

Имя объекта из 40 шестнадцатеричных чисел.

тип объекта

Тип объекта (аналог cat-file -t reports).

Размер объекта

Размер объекта в байтах (то же, что и cat-file -s
отчеты).

размер объекта: диск

Размер в байтах, занимаемый объектом на диске. Увидеть
обратите внимание на размеры на диске в разделе CAVEATS ниже.

deltabase

Если объект хранится как дельта на диске, он расширяется до
40-шестнадцатеричный sha1 базового объекта дельты. В противном случае расширяется до
null sha1 (40 нулей). См. CAVEATS ниже.

остальное

Если этот атом используется в выходной строке, входные строки разделяются
на первой границе пробела. Все персонажи до этого
пробелы считаются именем объекта; символы
после этого первого пробела (т.е.е., «остальная часть»
строка) выводятся вместо % (остального) атома .

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

Если указано --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 разрешений ссылок для разрешения). символа

  • Хэш 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
               Вместо содержимого покажите тип объекта, обозначенный .
    
           -s
               Вместо содержимого покажите размер объекта, обозначенный .
    
           -e
               Подавить весь вывод; вместо этого выйдите с нулевым статусом, если <объект> существует и является допустимым
               объект.
    
           -п
               Распечатайте содержимое  в зависимости от его типа.<тип>
               Обычно это соответствует реальному типу , но запрашивает тип, который может
               тривиально разыменовать данный <объект> также разрешено.  Примером является
               запросить "дерево" с , являющимся объектом фиксации, который его содержит, или запросить
               "blob", где  является объектом тега, который указывает на него.
    
           --textconv
               Показать содержимое, преобразованное фильтром textconv. В этом случае <объект> должен иметь
               форма :  или: , чтобы применить фильтр к содержимому
               записывается в индекс по <путь>.--batch, --batch = <формат>
               Распечатайте информацию об объекте и его содержимое для каждого объекта, представленного на стандартном вводе. Может не быть
               в сочетании с любыми другими вариантами или аргументами. См. Раздел BATCH OUTPUT ниже.
               подробности.
    
           --batch-check, --batch-check = <формат>
               Вывести информацию об объекте для каждого объекта, указанного на стандартном вводе. Не может сочетаться с
               любые другие варианты или аргументы. Подробности см. В разделе «ПАКЕТНЫЙ ВЫВОД» ниже. 
    
     
    

    ВЫХОД

           Если указан  -t , один из <тип>.Если указан  -s , размер <объекта> в байтах.
    
           Если указан  -e , вывода не будет.
    
           Если указано  -p , содержимое  печатается красиво.
    
           Если указан , необработанное (хотя и несжатое) содержимое  будет
           вернулся.
    
     
    

    ПАРТИЯ ВЫХОД

           Если задано --batch или --batch-check, cat-file будет читать объекты из stdin, по одному в строке,
           и распечатать информацию о них.По умолчанию вся строка рассматривается как объект,
           как если бы он был загружен на  git-rev-parse  (1).
    
           Вы можете указать информацию, отображаемую для каждого объекта, с помощью настраиваемого . В
            буквально копируется в стандартный вывод для каждого объекта с заполнителями формы
           % (атом) раскрывается с новой строкой. Доступные атомы:
    
           имя объекта
               Имя объекта из 40 шестнадцатеричных чисел. 
    
           тип объекта
               Тип объекта (то же, что и cat-file -t reports).размер объекта
               Размер объекта в байтах (такой же, как у отчетов cat-file -s).
    
           размер объекта: диск
               Размер в байтах, который объект занимает на диске. См. Примечание о размерах на диске
               в разделе «ПЕЩЕРЫ» ниже.
    
           дельтабаза
               Если объект хранится как дельта на диске, он расширяется до 40-шестнадцатеричного sha1 файла
               объект базы дельты. В противном случае расширяется до нуля sha1 (40 нулей). См. ПРЕДЛОЖЕНИЯ ниже.
    
           отдых
               Если этот атом используется в выходной строке, входные строки разделяются в первую очередь
               граница пробела.Все символы перед этим пробелом считаются
               имя объекта; символы после этого первого пробела (т. е. «остальная часть»
               строка) выводятся вместо атома% (остаток).
    
           Если формат не указан, по умолчанию используется формат% (имя объекта)% (тип объекта).
           % (размер объекта). 
    
           Если указан --batch, за информацией об объекте следует его содержимое.
           (состоящий из байтов% (размер объекта)), за которым следует новая строка.
    
           Например, --batch без специального формата выдаст:
    
                SP <тип> SP <размер> LF
               <содержание> LF
    
           В то время как --batch-check = '% (objectname)% (objecttype)' выдаст:
    
                SP  LF
    
           Если в stdin указано имя, которое не может быть преобразовано в объект в репозитории,
           тогда cat-файл проигнорирует любой пользовательский формат и напечатает:
    
               <объект> SP отсутствует LF
    
     

    ДЕЛО

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

    GIT

           Часть пакета  git  (1)
     

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

    Имя

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

    Сводка

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

    Описание

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

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

    Опции

    <объект>

    Имя отображаемого объекта. Более полный список способов написания имен объектов см. В разделе «УКАЗАНИЕ ИЗМЕНЕНИЙ» в
    git-rev-parse (1).
    Вместо содержимого покажите тип объекта, обозначенный .
    Вместо содержимого покажите размер объекта, обозначенного .
    Подавить весь вывод; вместо этого выйдите с нулевым статусом, если <объект> существует и является допустимым объектом.
    -п
    Довольно распечатайте содержимое <объекта> в зависимости от его типа.
    <тип>
    Обычно это соответствует реальному типу , но запрос типа, который можно тривиально разыменовать от данного , также
    разрешенный.Например, запросить «дерево» с , являющимся объектом фиксации, который его содержит, или запросить «blob» с , являющимся тегом.
    объект, указывающий на него.
    - партия
    Распечатайте SHA1, тип, размер и содержимое каждого объекта, предоставленного на стандартном вводе. Не может сочетаться с другими вариантами или аргументами.
    - партия-чек
    Распечатайте SHA1, тип и размер каждого объекта, указанного на стандартном вводе. Не может сочетаться с другими вариантами или аргументами.

    Выход

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

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

    Если указан -e , вывода не будет.

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

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

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

      SP <тип> SP <размер> LF
    <содержание> LF 
    Если указано --batch-check , вывод следующей формы печатается для каждого объекта, указанного в stdin:
      SP <тип> SP <размер> LF 
    Для --batch и --batch-check вывод следующей формы печатается для каждого объекта, указанного в stdin, который не существует в
    репозиторий:
     <объект> SP отсутствует LF 

    Автор

    Написано Линусом Торвальдсом < torvalds @ osdl. org [1] >

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

    Документация Дэвида Гривза, Джунио С. Хамано и git-list < [email protected]
    [2] >.

    Git

    Часть набора git (1)

    Банкноты

    1.

    [email protected]

    mailto: [email protected]
    2.

    [email protected]

    mailto: [email protected]

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

    Вы читаете
    Ry’s Git Tutorial

    В истории перезаписи я говорил о
    внутреннее представление репозитория Git.Возможно, я вас немного ввел в заблуждение.
    Хотя рефлог, интерактивная перестановка и сброс могут быть более сложными
    особенности Git, они по-прежнему считаются частью
    фарфор , как и все остальные команды, которые мы рассмотрели. В
    в этом модуле мы рассмотрим Git
    сантехника - низкоуровневые команды, которые дают нам доступ к
    Git истинное внутреннее представление проекта .

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

    Начнем с проверки объектной базы данных Git, а затем
    мы вручную создадим и зафиксируем моментальный снимок, используя только Git
    низкоуровневый интерфейс.

    Скачать репозиторий для этого модуля

    Если вы следовали инструкциям из предыдущего модуля, вы уже
    есть все необходимое.В противном случае загрузите заархивированный репозиторий Git из
    ссылку выше, распакуйте ее, и все готово.

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

    Во-первых, давайте подробнее рассмотрим нашу последнюю фиксацию с
    git cat-file команда сантехники.

      git   cat-file   commit   HEAD 
     

    Параметр commit сообщает Git, что мы хотим увидеть фиксацию
    объект, и, как мы уже знаем, HEAD относится к самому последнему
    совершить.Это выведет следующее, хотя ваши идентификаторы и информация о пользователе
    будет иначе.

     дерево 552acd444696ccb1c3afe68a55ae8b20ece2b0e6
    родитель 6a1d380780a83ef5f49523777c5e8d801b7b9ba2
    автор Райан  1326496982 -0600
    коммиттер Райан  1326496982 -0600
    
    Добавить файл .gitignore
     

    Это полное представление фиксации: дерево, родитель, пользователь.
    данные и сообщение фиксации. Информация о пользователе и сообщение о фиксации
    относительно просто, но мы никогда не видели дерево или
    родительских значений ранее.

    Древовидный объект - это представление Git
    «Снимки», о которых мы говорим с начала
    этот учебник. Они записывают состояние каталога в заданный момент, без
    любое понятие времени или автора. Чтобы связать деревья в единый проект
    history, Git заключает каждый из них в объект фиксации и указывает
    родительский , это просто еще один коммит. Следуя за родителем
    каждого коммита вы можете просмотреть всю историю проекта.

    Объекты фиксации и дерева

    Обратите внимание, что каждая фиксация относится к одному и только одному объекту дерева. От
    git cat-file output, мы также можем сделать вывод, что деревья используют SHA-1
    контрольные суммы для их идентификаторов. Так будет со всеми
    внутренние объекты.

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

    Затем давайте попробуем проверить дерево с помощью того же git
    cat-file
    команда. Обязательно измените 552acd4 на идентификатор
    ваше дерево из предыдущего шага.

      git   cat-файл   дерево   552acd4 
     

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

      git   ls-tree   552acd4 
     

    Это выведет содержимое дерева, которое очень похоже на
    список в каталоге:

     100644 blob 99ed0d431c5a19f147da3c4cb8421b5566600449 .gitignore
    040000 дерево ab4947cb27ef8731f7a54660655afaedaf45444d о нас
    100644 blob cefb5a651557e135666af4c07c7f2ab4b8124bd7 blue.html
    100644 blob cb01ae23932fd9704fdc5e077bc3c1184e1af6b9 зеленый.html
    100644 blob e993e5fa85a436b2bb05b6a8018e81f8e8864a24 index.html
    100644 blob 2a6deedee35cc59a83b1d978b0b8b7963e8298e9 news-1.html
    100644 blob 0171687fc1b23aa56c24c54168cdebaefecf7d71 news-2.html
    ...
     

    Изучив вышеприведенный вывод, мы можем предположить, что «капли»
    представляют файлы в нашем репозитории, а деревья представляют папки. Вперед, продолжать
    и исследуем дерево около с другим git ls-tree
    чтобы увидеть, так ли это на самом деле. Вы должны увидеть содержание нашего
    около папки.

    Итак, объектов BLOB-объектов - это то, как Git хранит данные нашего файла, дерево
    объекты объединяют капли и другие деревья в список каталогов, а затем фиксируют
    объекты связывают деревья в историю проекта. Это единственные типы объектов
    что Git необходимо реализовать почти все фарфоровые команды, которые мы
    использовались, и их отношения суммируются следующим образом:

    Объекты фиксации, дерева и больших двоичных объектов

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

    Давайте посмотрим на каплю, связанную с синим цветом .html
    (обязательно измените следующий идентификатор на идентификатор рядом с blue.html в
    ваш вывод дерева ).

      git   cat-файл   blob   cefb5a6 
     

    Это должно отобразить все содержимое blue.html ,
    подтверждение того, что большие двоичные объекты действительно представляют собой простые файлы данных. Обратите внимание, что капли чистые
    content: в приведенном выше выводе не упоминается имя файла. То есть,
    имя blue.html хранится в дереве , которое содержит
    blob
    , а не сам blob.

    Вы можете вспомнить из Основы, что SHA-1
    контрольная сумма гарантирует, что содержимое объекта никогда не будет повреждено без Git
    зная об этом. Контрольные суммы работают, используя содержимое объекта для
    создать уникальную последовательность символов. Это не только функция идентификатора,
    это также гарантирует, что объект не будет незаметно поврежден (
    измененный контент будет генерировать другой идентификатор).

    Когда дело доходит до больших двоичных объектов, это дает дополнительное преимущество. С двух
    BLOB-объекты с одинаковыми данными будут иметь одинаковый идентификатор, Git должен совместно использовать BLOB-объекты
    через несколько деревьев.Например, наш файл blue.html
    не менялся с момента создания, поэтому наш репозиторий будет только
    имеют один связанный BLOB-объект, и все последующие деревья будут ссылаться на него. От
    не создавая повторяющиеся капли для каждого объекта дерева, Git значительно уменьшает размер
    репозитория. Имея это в виду, мы можем изменить нашу диаграмму объектов Git на
    следующий.

    Фиксация, дерево и общие объекты BLOB-объектов

    Однако, как только вы измените одну строку в файле, Git должен создать
    новый объект blob, потому что его содержимое будет изменено, что приведет к новому
    Контрольная сумма SHA-1.

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

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

      git   cat-файл   тег   v2.0 
     

    Это выведет идентификатор фиксации, связанный с v2.0 , вместе с
    название тега, автор, дата создания и сообщение. Прямолинейный
    связь между тегами и коммитами дает нам финализированный объект Git
    диаграмма:

    Объекты фиксации, дерева, большого двоичного объекта и тега

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

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

      git   cat-файл   -t   master 
     

    Верно, ветка - это просто ссылка на объект фиксации, который
    означает, что мы можем просмотреть его с помощью обычного git cat-файла .

      git   cat-file   commit   master 
     

    Это выведет ту же информацию, что и наш исходный git
    cat-файл коммит HEAD
    .Вроде как master ветка
    и HEAD - это просто ссылки на объект фиксации.

    С помощью текстового редактора откройте файл .git / refs / Heads / master .
    Вы должны найти контрольную сумму самой последней фиксации, которую вы можете
    просмотреть с помощью git log -n 1 . Этот единственный файл - это все, что нужно Git
    поддерживать главную ветвь - вся остальная информация
    экстраполировано через описанные выше отношения объектов фиксации.

    Ссылка HEAD , с другой стороны, записана в
    .git / HEAD . В отличие от наконечников веток, HEAD не является
    прямая ссылка на коммит. Вместо этого он ссылается на ветку, которую Git использует для
    выяснить, какая фиксация в настоящее время проверена. Помните, что
    ОТДЕЛЕННАЯ ГОЛОВКА Состояние произошло, когда ГОЛОВА не сделала
    совпадают с верхушкой любой ветки. Внутренне для Git это означает, что
    .git / HEAD не содержит локального ответвления. Попробуйте проверить
    старый коммит:

      git   checkout   HEAD ~ 1 
     

    Сейчас, .git / HEAD должен содержать идентификатор фиксации вместо ветки.
    Это сообщает Git, что мы находимся в состоянии отсоединения HEAD .
    Независимо от того, в каком состоянии вы находитесь, команда git checkout
    всегда будет записывать извлеченную ссылку в .git / HEAD .

    Прежде чем двигаться дальше, вернемся к нашей ветке master :

      git   checkout   master 
     

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

    Хотя у нас есть базовые представления о взаимодействии с объектами Git, мы
    еще предстоит изучить, где Git хранит все эти объекты.В твоей
    Репозиторий my-git-repo , откройте папку .git / objects .
    Это объектная база данных Git.

    Каждый объект, независимо от типа, сохраняется в виде файла с использованием его контрольной суммы SHA-1.
    как имя файла (вроде). Но вместо того, чтобы хранить все объекты в одном
    папки, они разделяются с использованием первых двух символов их идентификатора в качестве
    имя каталога, в результате чего база данных объектов выглядит примерно так
    следующий.

     00 10 28 33 3e 51 5c 6e 77 85 95 f7
    01 11 29 34 3f 52 5e 6f 79 86 96 f8
    02 16 2a 35 41 53 63 70 7a 87 98 f9
    03 1c 2b 36 42 54 64 71 7c 88 99 fa
    0c 26 30 3c 4e 5a 6a 75 83 91 a0 информация
    0e 27 31 3d 50 5b 6b 76 84 93 a2 pack
     

    Например, объект со следующим ID:

     7a52bb857229f89bffa74134ee3de48e5e146105
     

    хранится в папке с именем 7a , используя оставшиеся символы.
    ( 52bb8... ) как имя файла. Это дает нам идентификатор объекта, но раньше
    мы можем проверять элементы в базе данных объектов, нам нужно знать, какой тип
    объект это. Опять же, мы можем использовать флаг -t :

      git   cat-файл   -t   7a52bb8 
     

    Конечно, измените идентификатор объекта на объект с вашей базы данных
    (не забудьте объединить имя папки с именем файла, чтобы получить
    полный ID). Это выведет тип фиксации, который мы затем можем передать в
    нормальный вызов git cat-file .

      git   cat-файл   blob   7a52bb8 
     

    Моим объектом был капля, но ваш может быть другим. Если это дерево,
    не забудьте использовать git ls-tree , чтобы превратить эти уродливые двоичные данные в
    красивый список каталогов.

    Собери мусор

    По мере роста вашего репозитория Git может автоматически передавать ваши объектные файлы.
    в более компактную форму, известную как «пакетный» файл. Вы можете заставить это
    сжатие с помощью команды сборки мусора, но будьте осторожны: эта команда
    невозможно.Если вы хотите продолжить изучение содержимого
    .git / objects , вы должны сделать это перед запуском следующего
    команда. Обычная функциональность Git не пострадает.

      git   gc 
     

    Сжимает отдельные объектные файлы в более быстрый и компактный пакетный файл и
    удаляет болтающиеся коммиты (например, из удаленной несвязанной ветки).

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

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

    До сих пор мы обсуждали низкоуровневое представление Git
    совершенных снимков. Остальная часть этого модуля будет переключать передачи и использовать больше
    «Сантехнические» команды для ручной подготовки и фиксации нового снимка.
    Это даст нам представление о том, как Git управляет рабочим каталогом и
    плацдарм.

    Создайте новый файл с именем news-4.html в
    my-git-repo и добавьте следующий HTML-код.

       
        lang =   "en"  > 
       
         </code> Вторжение индиго <code>  
        <ссылка   rel =   "таблица стилей"   href =   "style.css"   /> 
          charset =   "utf-8"   /> 
       
       
        

    style = "color: # A0C" > Indigo Invasion

    На прошлой неделе коалиция азиатских дизайнеров, художников, и рекламодатели объявили официальный цвет Азии: style = "цвет: # A0C" > Indigo .

    href= "index.html" > Вернуться на главную страницу

    Затем обновите раздел index.html «Новости», чтобы он соответствовал
    следующие.

      

    style = "color: # C00" > News

    Вместо git add мы будем использовать низкоуровневый git
    update-index
    , чтобы добавить файлы в промежуточную область. В
    index - это термин Git для поэтапного снимка.

      git   статус 
      git   update-index   index.html 
      git   update-index   news-4.html 
     

    Последняя команда выдаст ошибку - Git не позволит вам добавить новый
    файл в индекс без явного указания, что это новый файл:

      git   update-index   --add   news-4.html 
      git   статус 
     

    Мы только что переместили рабочий каталог в индекс, что означает, что мы
    подготовьте снимок для принятия решения. Однако процесс не будет
    так же просто, как git commit .

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

    Помните, что все коммиты относятся к объекту дерева, который представляет
    снимок для этого коммита. Итак, перед созданием объекта фиксации нам нужно добавить
    наш индекс (поэтапное дерево) в объектной базе данных Git.Мы можем сделать это с
    следующую команду.

      git   дерево записи 
     

    Эта команда создает объект дерева из индекса и сохраняет его в
    .git / объекты . Он выведет идентификатор результирующего дерева (ваш
    может быть другим):

     5f44809ed995e5b861acf309022ab814ceaaafd6
     

    Вы можете проверить свой новый снимок с помощью git ls-tree . Держать в
    помните, что единственные новые капли, созданные для этого коммита, были
    index.html и новости-4.html . Остальная часть дерева
    содержит ссылки на существующие капли.

      git   ls-tree   5f44809 
     

    Итак, у нас есть объект-дерево, но мы еще не добавили его в проект
    история.

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

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

      git   журнал   --oneline   -n   1 
     

    Это выведет следующую строку, хотя ваш идентификатор фиксации будет
    разные.Мы будем использовать этот идентификатор, чтобы указать родителя нашей новой фиксации.
    объект.

      3329762  Добавить файл .gitignore
     

    Команда git commit-tree создает объект фиксации из дерева
    и родительский идентификатор, в то время как информация об авторе берется из среды
    переменная, установленная Git. Обязательно измените 5f44809 на свой идентификатор дерева,
    и 3329762 на ваш последний идентификатор фиксации.

      git   дерево фиксации   5f44809   -p   3329762 
     

    Эта команда будет ждать дополнительных входных данных: сообщения фиксации. Тип Добавить
    4-я новость
    и нажмите Введите , чтобы создать сообщение фиксации,
    затем Ctrl-Z и Введите для Windows или
    Ctrl-D для Unix, чтобы указать символ «Конец файла»
    чтобы закончить ввод. Как и команда git write-tree , это будет
    вывести идентификатор полученного объекта фиксации.

     c51dc1b3515f9f8e80536aa7acb3d17d0400b0b5
     

    Теперь вы можете найти этот коммит в .git / objects ,
    но ни HEAD , ни ветки не были обновлены для включения
    этот коммит.На данный момент это болтающийся коммит . к счастью
    для нас мы знаем, где Git хранит информацию о своих филиалах.

    Создание зависшей фиксации

    Обновление HEAD

    Поскольку мы не находимся в состоянии отсоединения HEAD ,
    HEAD - ссылка на ветку. Итак, все, что нам нужно сделать, чтобы обновить
    HEAD - это перемещение основной ветки в нашу новую
    зафиксировать объект. С помощью текстового редактора замените содержимое
    .git / refs / Heads / master с выводом из git
    commit-tree
    на предыдущем шаге.

    Если этот файл исчез, не волнуйтесь! Это просто означает
    что команда git gc собрала все наши ссылки на ветки
    в один файл. Вместо .git / refs / Heads / master откройте
    .git / pack-refs , найдите строку с
    refs / Heads / master и измените идентификатор слева от него.

    Теперь, когда наша ветка master указывает на новую фиксацию, мы должны
    увидеть файл news-4.html в истории проекта.

      git   журнал   -n   2 
     

    Последние четыре раздела объясняют все, что происходит за кулисами.
    когда мы выполняем git commit -a -m "Some Message" . Разве ты не
    рада, что тебе больше не придется пользоваться сантехникой Git?

    Обновление вручную master ветка

    Заключение

    После этого модуля вы, надеюсь, хорошо разбираетесь в базе данных объектов.
    это лежит в основе почти каждой команды Git.Мы изучили коммиты, деревья, капли,
    теги и ветки, и мы даже создали объект фиксации с нуля. Все
    это должно было дать вам более глубокое понимание фарфора Git
    команд, и теперь вы должны быть готовы адаптировать Git практически под любую задачу, которую вы
    может потребоваться от системы контроля версий.

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

    На этом мы завершаем наше путешествие по системе контроля версий на основе Git. Этот учебник
    был предназначен для того, чтобы подготовить вас к реалиям распределенного ПО
    разработка - не для того, чтобы в одночасье превратить вас в эксперта по Git. Вам следует
    иметь возможность управлять своими проектами, сотрудничать с другими пользователями Git и,
    возможно, самое главное, точно понимать, что любой другой кусок Git
    документация пытается передать.

    Ваша задача сейчас - применить эти навыки в новых проектах, отсеять
    через сложные истории, которых вы никогда раньше не видели, поговорите с другими
    разработчиков об их рабочих процессах Git, и не торопитесь, чтобы попробовать все
    те сценарии «Интересно, что бы произошло, если бы…».Удачи!

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

    git cat-file <тип> <идентификатор-объекта>
    Отобразить указанный объект, где <тип> - одно из
    фиксация , дерево , blob или
    тег .
    git cat-file -t <идентификатор-объекта>
    Вывести тип указанного объекта.
    git ls-tree <идентификатор-дерева>
    Показать красивую версию указанного объекта дерева.
    git gc
    Выполните сборку мусора в базе данных объектов.
    git update-index [--add] <файл>
    Подготовьте указанный файл, используя необязательный флаг --add в
    обозначают новый неотслеживаемый файл.

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

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    2021 © Все права защищены. Карта сайта