GIT: как прочитать файл в любом комите без checkout

[RXL]

Давненько ничего не писал. Хочу сделать небольшую серию записей на память о GIT. Это не для всех, только для автоматизаторов и извращенцев.

Получить хеш дерева по хешу комита $commit_hash:

$tree_hash=$(git cat-file -p $commit_hash | grep '^tree ' | sed -E 's/^tree\s+(\S+).*/\1/)

Прочитать файл $file_name:

$content=$(git cat-file -p $tree_hash:$file_name)

[Люсь]

аффтар, пеши исчо!

[Джон]

Можно ли считать извращенцем (или автоматизатором?  ) человека, который хочет "почистить" папку проекта .git?

[RXL]

У меня целая библиотечка на perl с такими штуками. Вплоть до ручного коммита.

Есть еще случай. Когда нужно держать на сервере кучку инстансов одного и того же приложения под одним юзером, можно сэкономить на кеше объектов гита. Инстанс у меня весит 50 ГБ. Кеш весит более половины от этого.

Т.ч., будет время, поделюсь.

[RXL]

Можно ли считать извращенцем (или автоматизатором?  ) человека, который хочет "почистить" папку проекта .git?

Что значит "почистить"? Если ему всегда грязно — ну пусть почистит. А есть это "ухудить", то надо смотреть конкретный случай. Обычно это да, извращение.

[Джон]

Обычно это да, извращение.

Ок, тогда "я удачно зашёл" (с)

Насколько я понимаю, в .git находится вся исторя изменений, но если она мне не нужна? Те если вдруг, то я могу на сервере посмотротеть.
А так папка 12 ГБ, накой она мне нужна?

А есть это "ухудить"

С этого момента, будьте добры, помедленнее, я буду записывать...

зы "Почистить" - в смысле, например, удалить историю изменений последних двух лет, оставив скажем последнюю неделю, ну, или месяц.

зы зы Если это возможно

[RXL]

Сперва надо терминологию устаканить. Если я правильно понял, ты историей называешь дерево коммитов, то тут можно сделать клон с ограниченной глубиной (--depth). И да, это извращение и может сослужить медвежью услугу. Например, ветки могут оказаться не на общем дереве, а на отдельных несвязанных деревьях. Так же не удастся сделать blame (покажет в рамках доступной локально информации) и вообще трудности с ретроспективой (люблю делать git log --patch и git log -L<start_line>,<stop_line>:<file>).

Моему проекту 12 лет и порой дохожу до глубины глубин, чтобы понять, откуда эта хрень тут взялась и в чем ее смысл. Переводил несколько лет назад на git с svn без потери истории.
А вот сабрепы со "статикой" (графика, локализация, и всякие бинари) — тут согласен, можно деинсталить сабрепу, вычистить руками ее кеш и обновить с указанием глубины (git submodule update --init --depth <N>).
И очень не советую использовать lfs: десять раз подумать, прежде чем использовать. Много минусов и противопоказаний. Я все свои 50 ГБ без lfs держу. Вот если одни и те же бинари часто изменяются, то можно же подумать одиннадцатый раз.

[Люсь]

Ок, тогда "я удачно зашёл" (с)

Получается, это я удачно реанимировала, раз кому-то это актуально )))))

[Джон]

Ром, всё понял. Спасибо. Оставлю так.

Люсь, персонально спасибо.

[RXL]

Достоинства git в том, что каждый клон может выступать как основная копия. Если, конечно, он склонировал все, что нужно для автономности. А еще можно в одной и той же репе сделать больше одного дерева, но надо только чтобы они по именам веток не пересекались. Хотя, какое оно к черту дерево. Это граф полноценный, хоть и с корнем.

Кстати, Жень, а у вас main, master, develop или trunk?  

[Люсь]

Ром, всё понял. Спасибо. Оставлю так.

Люсь, персонально спасибо.

персональное на здоровье ))))

[Джон]

Кстати, Жень, а у вас main, master, develop или trunk? 

master

Дело в том, что я локально git ваще не юзаю. В основном он (мне) служит для передачи данных (commit -> push) на сервер для хранения и компиляции, изредка для merge, когда коллега в проекте участвует.
Опять же, в этом случае я просто делаю pull и всё.

Короче, примерно как Ворд в качестве редактора тхт файлов.

Раньше у нас был локальный серевер компиляции и SVN, лет несколько назад перешли на Azure, которая больше git "любит", ну и вот...

[RXL]

Понятно. Значит будем писать заметки про гит )

[Алексей++]

Джон, RXL, а я вот пользуюсь гитом только локально, логин - почта. И однажды мне было нужно пушить копию фрилансерскому работодателю. Столкнулся с проблемой - там логин свой. Помнится, не разобрался, как при пуше на два репозитория одновременно использовать разные логины. Это возможно?

Тогда в виде костыля свой логин сделал таким же, а после окончания сотрудничества вернул свой. Локально мне, по большом счёту, пофиг, но вот сейчас вспомнил этот осадочек
Использую оболочку TortoiseGit , вручную не консолюсь

[RXL]

Удаленные репозитории именуются remotes. Их может быть сколько угодно и у каждого может быть свой протокол связи, а, соотв., и авторизации. Дефолтный зовется origin.

git remote --help — чтобы понять, как создать и удалить.
git push <remote_name> <local_branch_name>:<remote_branch_name> — чтоб отослать свою local_branch_name на удаленную remote_branch_name.
git push <remote_name> <branch_name> — это если имена веток совпадают

Напрямую, из консоли, намного все проще и понятнее, конечно, если знаешь команды. Там встроенный help: git <command> --help — читай на здоровье!
Черепашка разрабатывалась под SVN и потому она такая странная с GIT. Мы на работе отдельную доку писали для ее пользователей, чтобы ни шагу в сторону от инструкции.
И вот от всего этого пользователи говорят, что GIT — это сложно. На самом деле, GIT — это очень просто, если с точки зрения архитектуры. Пользовательский интерфейс, да, не очень, даже в командной строке.

Насчет простоты архитектуры. Загляните в .git/config — там много интересного. Тот же ini, только чуть-чуть расширен в именах секций.

[Алексей++]

спасибо, поэкспериментирую при случае. Хорошо, что способ есть

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

[RXL]

Черепашка достаточно позволяет, но ее опции разбросаны, скажем так, не достаточно структурировано и, даже зная, как пишутся команды в консоли (а все в итоге к ним и сведется), трудно понять, какие галочки включить, а какие выключить. В любом случае, лучше сперва понять на низком уровне, а потом прийти к пониманию, как эти галочки на него мапируются.