Alt linux install git

На самом деле не про git как таковой, а про git применительно к ALT Linux и git.alt; некое подобие QuickStart по git@ALT для присматривающихся участников team — здесь.

В качестве введения в git смотрите Управление исходным кодом с помощью Git (на русском языке) и Everyday GIT (на английском языке).

Примечание: все примеры команд, указываемых через дефис (например, git-clone) на последних версиях Git следует применять без дефиса, заменив его пробелом: git clone.

Содержание

GEAR [ править ]

В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя gear. Напомню вкратце:

Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно git+sed) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство собирать пакеты из произвольных srpm-пакетов.

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

На всякий случай рекомендую установить/обновить пакет gear, а также освежить в своей памяти содержимое файлов /usr/share/doc/gear-1.4.0/QUICKSTART.ru.html и /usr/share/doc/git-1.5.5.3/tutorial.html

Структура репозитория [ править ]

Как уже было сказано, gear не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов:

Одна сущность — один репозиторий. Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями. Отрицательная сторона: несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает.
Несжатый исходный код. Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (git-diff). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных. Отрицательная сторона: поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.
Распакованный исходный код. Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении). Отрицательная сторона: поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.
Аккуратный changelog. В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты gear-commit (обёртка к git-commit, специально предназначенная для этих целей) и gear-srpmimport. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета.

Инструкция по эксплуатации git.altlinux.org [ править ]

Для преодоления барьеров вида «админ закрыл наружу всё и оставил только прокси» ssh на git.altlinux.org доступен также и на порту 443, что можно использовать.

По всем вопросам, связанным с этой частью инструкции, пишите на join@.

Клонировать к себе на компьютер свой репозиторий с git.altlinux.org (SSH предварительно настроен):

Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org:

Залить на git.alt свой ранее созданный git-репозиторий:

Представим, что некий foo сделал какие-либо изменения для нашего пакета bar в бранче bar-bugfree и выложил их на git.alt. Узнаем, как называется его этот бранч:

Далее зафетчим этот бранч к нам с одноименным названием:

Дальше работаем с ним как хотим 😉

Удалить бранч на git.alt (задав пустое имя локального бранча):

Копирование файлов из одного бранча в другой:

и устаревший способ:

Ответы на часто забываемые вопросы [ править ]

«Как найти мейнтейнера?» [ править ]

http://sisyphus.ru/srpm/spt/gear (с датами и ссылками)
http://git.altlinux.org/people-packages-list
см. ниже:

Читайте также: Сервер для windows компа

> Слить сорцы из git’а, сделать патч и отправить автору (да, в мире существуют
> другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того
> типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual
> mantainers, которых почти всё устраивает, но иногда хочется написать патчик и
> отправить обратно.

В принципе, даже той информации, которая есть в бинарном пакете сейчас, уже достаточно для casual mantainers:

1. В установленном бинарном пакете есть % (виден по rpmquery -i), из которого однозначно вычисляется имя исходного пакета.

2. Далее, в установленном бинарном пакете есть % (виден по rpmquery —lastchange).

3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень высокой вероятностью предположить, что если пакет был собран из git-репозитория, то этот репозиторий называется http://git.altlinux.org/people/MAINT/packages/?p=PKG.git

Как вести пакет в git [ править ]

Там правда апстрим git-овый, но это сути не меняет. .gear-rules там состоит из одной строчки — вот такой:

@name@ и @version@ берутся из спека. @name@ — это liblazy. а @version@ — это 0.1

На ветке upstream присутствует тег liblazy-0.1. Поэтому апстримный тарбол будет браться из этого тега.

При переезде на новую версию надо будет всего лишь:

1. Поставить нужный тег на апстримной ветке (например liblazy-0.2).
2. Смержить этот тег в master с -s ours
3. Заменить в спеке версию с 0.1 на 0.2.
4. Выполнить gear-update-tag -ac
5. Дописать changelog

Как втащить пакет из Сизифа, если его нет на git.alt/people [ править ]

Пакет, который давно не собирался или заброшен, или его мейнтейнер не пользуется git.alt, можно найти в архиве Сизифа. Архив Сизифа содержит последние версии когда-либо собиравшихся в Сизиф пакетов (с историей) и доступен по ssh git.alt в каталоге /archive. Для удобства хранилища собраны в двухуровневое дерево (по первой букве), без различия мейнтейнеров.

Таким образом на сегодня git-clone git.alt:/archive/m/mkimage отдаст хранилище, соответствующее текущему пакету mkimage в Сизифе, кто бы его ни собрал на этот раз.

workflow [ править ]

Совместная работа над пакетами в git строится по следующей схеме:

При дальнейшей работе сценарий повторяется, за исключением того, что B не клонирует репозиторий A/X, а подтягивает (pull) из него новые изменения.

Как это реализуется на практике?

Для поиска репозитория для клонирования используется команда find-package:

Склонировать репозиторий можно с помощью команды clone:

Эта команда создаст вашу копию репозитория на сервере git.alt. Для работы с ним необходимо склонировать этот репозиторий на локальную машину:

С этим git-репозиторием можно работать как обычно: править, делать commit и так далее. Поскольку для склонированного репозитория создаётся remote с названием origin, то git-push тоже работает:

Нотификации производятся вручную — почтой или через bugzilla. Аналога pull request из github или gitorious на git.alt пока что нет.

Втягивание чужих изменений производится стандартными git-средствами: добавлением remote

и отправкой в git.alt:

Удаление удалённых веток в git [ править ]

Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине — сделайте в него push из «никакой» ветки:

или если хотите удалить тег:

Полная форма push выглядит так:

где — имя локальной ветки, из которой берутся данные, а — имя ветки в удалённом репозитории, куда происходит их передача с замещением имеющегося. Привычный вид git push является лишь одной из реализаций этой полной формы.

Источник

git.alt/Краткое руководство

Материал из ALT Linux Wiki

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

Содержание

Настройка

Убедитесь, что ваш SSH-ключ зарегистрирован принимающими в команду, и проведите настройку в соответствии с описанием в справочнике.

Дальнейшая инструкция подразумевает, что ssh-клиент настроен в соответствии с описанием в справочнике по git.alt, в частности, в конфигурационном файле

/.ssh/config есть хосты с именами git.alt и gitery.alt.

Клонирование чужого репозитория для работы над ним

Для поиска репозиториев используется команда find-package (результатов может быть и больше):

Склонировать репозиторий можно с помощью команды clone:

Эта команда создаст вашу копию репозитория на сервере git.alt. Для работы с ним необходимо склонировать этот репозиторий на локальную машину [1] :

Создание нового репозитория и работа над ним

Создать свой репозиторий на git.alt очень просто [2] :

Поскольку в созданном репозитории нет ни одного коммита, то git clone будет ругаться при попытке его склонировать. Если необходимо создать пустой локальный репозиторий [3] :

Закоммитить в него нужное содержимое и отправить на gitery.alt [4] :

Подробное пояснение действий:

Создаётся файл README
touch README
Файл добавляется в список изменённых файлов для фиксирования (коммита) в локальный git-репозиторий
git add README
Происходит фиксация изменений в текущей ветке (бранче, по умолчанию master) локального git-репозитория с комментарием
git commit -m ‘first commit’
Связывается локальный git-репозиторий с удалённым git-репозиторием, расположенным на gitery.alt:packages/test.git , притом удалённый git-репозиторий в локальном репозитории получает имя origin
git remote add origin gitery.alt:packages/test.git
Добавляется ветка master и все изменения, зафиксированные в ней, в удалённый репозиторий с именем origin
git push origin master

Указание локального имени удалённого репозитория origin и бранча master в команде push необходимо только в первый раз для создания бранча master в удалённом репозитории. git remote add создаёт в конфиг-файле локального репозитория [5] запись, подобную такой:

И поэтому в дальнейшем git push будет отправлять в удалённый репозиторий все локальные ветки ( refs/heads/* ), по названию соответствующие удалённым ( refs/remotes/origin/* ).

Сборка пакета в Сизиф

Создаём подписанный тэг (при установленном пакете gear вместо git tag удобней воспользоваться gear-create-tag ):

Отправляем пакет на сборку в Сизиф:

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

Сборка пакета в другие поддерживаемые репозитории

Помимо Сизифа пакет можно отправить в другой репозиторий; например, branch/5.1.

Cписок репозиториев можно получить с помощью команды ssh git.alt task new --help. Пример:

Отдельным локальным бранчем (например, t6) оформляем спек согласно backports policy, коммитим [6] и создаём подписанный тэг [7] :

Отправляем пакет на сборку:

Сборка группы пакетов

Создаём подписанные тэги для репозиториев:

Создаём задачу для сборки:

Добавляем репозитории и тэги:

Альтернативно, вместо последовательности команд task new, task add и task run создать и отправить задание на сборку можно так:

Перекладывание (копирование) собранного пакета

Этот пример демонстрирует копирование пакета из Sisyphus в t6/branch:

При копировании пакетов из Sisyphus существует более простой способ добиться того же результата:

Результат сборки

Результат выполнения задания вы можете посмотреть на

где — номер присвоенного задания. Или статус собственных задач на git.alt:

Удаление пакета

Осуществляется путем создания задания с запросом на удаление. Пример:

Источник

Alt linux install git

Git-svn

Содержание

Создаём новый git-репозиторий [ править ]

Конвертируем существующий git-репозиторий [1] [ править ]

.gear/rules [ править ]

Накладывание патчей [ править ]

Новые upstream-версии [ править ]