git/BranchInGit

Приёмы работы с пакетами в git

15:44 < Lost> обновился апстрим например
15:44 < Lost> делаю git checkout upstream
15:44 < swi> git co patch; git merge upstream; git co master; git merge patch?
15:44 < Lost> git-tag -s 'KoLmafia-11.5' например или что-то типа того, чтобы зафиксировать ревизию
15:45  * swi заткнулся и внимает
15:45 < Lost> далее делаю git-checkout equipment-fixes (ветка с приложенным патчем)
15:45 < Lost> git-merge KoLmafia-11.5 (тег, полученный при предыдущем шаге)
15:46 < Lost> можно в принципе делать git-merge upstream -
будет то же самое, но тег как-то солиднее, да и нужен он будет позднее
15:46 < Lost> далее смотрю, ровненько ли прошел merge, не надо ли чего подправить
15:46 < Lost> если все в порядке, кладу еще один тег
15:47 < Lost> git-tag -s equipment-11.5
15:47 < Lost> теперь патчик мой будет генериться между двумя этими тегами
15:47 < Lost> далее git-checkout master
15:47 < Lost> git-merge equipment-11.5
15:47 < Lost> gear-update-tag KoLmafia-11.5
15:47 < Lost> gear-update-tag equipment-11.5
15:48 < Lost> это вносит новые теги в специальную папочку .gear-tags
15:48 < Lost> чтобы gear их мог видеть
15:48  * swi кивнул
15:48 < Lost> а дальше нужны хитрые строчки в .gear-rules
15:49 < Lost> первая строчка - tar.gz: KoLmafia-11.5:KoLmafia
15:49 < Lost> это говорит геару, что тарбол надо брать из тега KoLmafia-11.5 (ну то есть апстрима)
15:49 < swi> ооо
15:50 < Lost> следующая строчка - diff: KoLmafia-11.5:KoLmafia equipment-11.5:KoLmafia name=<имя патчега>
15:50 < Lost> это говорит что патчег <имя патчега> надо брать путем сравнения двух тегов
15:51 < Lost> первый находится на ветке upstream, второй - на ветке equipment-fixes
15:51 < Lost> ну а дальше прописываю этот патчег в KoLmafia.spec
15:51 < Lost> и как обычно, %patch0 -p1 :)
15:52 < swi> оооооооооооооо
15:52 < Lost> увеличиваю релиз/версию в спеке, add_changelog, заполняю ченджлог, потом проверочная сборка
15:52 < swi> я б сказал даже вау.. но не гламурен
15:52 < Lost> если все в порядке - тогда gear-commit -a
15:52 < Lost> а потом gear-create-tag (новая приблуда в новом геаре)
15:53 < Lost> она создаст тег релиза, по которому в будущем вроде как должна запускаться автоматическая сборка

11:54 < Lost> ну типа так:
11:54 < Lost> mkdir qtemu
11:54 < Lost> cd qtemu
11:54 < Lost> tar -xf qtemu-0.3.tar.gz
11:54 < Lost> mv qtemu-0.3 qtemu
11:54 < Lost> git-init
11:54 < Lost> git-add qtemu
11:54 < Lost> git-commit -m 'Initial import of qtemu-0.3'
11:55 < Lost> git-checkout -b upstream
11:55 < Lost> git-tag -m 'qtemu-0.3' -s qtemu-0.3
11:56 < Lost> потом сразу импортишь следующий релиз
11:56 < Lost> gear-update ~/tmp/qtemu-0.4.tar.gz qtemu && git-commit -a -m 'qtemu-0.4' && git-tag -m 'qtemu-0.4' -s qtemu-0.4
11:57 < Lost> то есть у тебя в ветке upstream получатся последовательные релизы, каждый из которых обозначен тегом
11:57 < Lost> далее ты делаешь git-checkout master
11:57 < Lost> добавляешь .gear-rules и спек от qtemu-0.3-alt1
11:58 < Lost> коммитишь
11:58 < Lost> ну и т.д. Потом делаешь git-merge qtemu-0.4 и коммитишь спек от qtemu-0.4-alt1

16:53 < stanv> а как можно сразу все бранчи забрать ?
16:58 < Lost> stanv: а зачем?
16:59 < Lost> вроде отдельной команды нету для этого
16:59 < stanv> :) например доступа к origin не всегда есть :)
17:00 < Lost> stanv: не понял про доступ
17:01 < stanv> ну выключили инет, и на remote branch перейти (взять себе) уже не сможешь
17:01 < Lost> stanv: чаво?
17:01 < Lost> ты упал чтоли?
17:02 < Lost> если ты сделал git-clone, у тебя полная копия репозитория
17:02 < Lost> со всеми тагами, бранчами и прочим
17:02 < Lost> дальше тебе исходный репо нужен только для git-push и git-pull
17:02 < stanv> только теперь к имени бранчам появился префикс origin ?
17:04 < Lost> stanv: эти бранчи стали remotes
17:04 < Lost> stanv: они отслеживают состояние бранчей в исходном репо
17:04 < Lost> их менять низя
17:04 < Lost> зато из них можно делать свои локальные бранчи
17:04 < stanv> аа!
17:05 < stanv> прозрел :)
17:08 < stanv> еще про tags роскажи и все :) tag - это commit в ветке. если я удалю ветку, все таги для коммитов этой ветки тоже удалятся *
17:08 < stanv> ?
17:08 < Lost> tag - это сцылко на коммит
17:08 < Lost> сам по себе он является таким же полноправным ref, как и ветко
17:09 < Lost> если ты удалишь ветку, таг останеццо
17:09 < stanv> и ?
17:09 < Lost> таг отличается от ветки тем, что в ветку можно коммитить
17:10 < Lost> и то, что таг может быть объектом (полновесный таг то есть)
17:10 < Lost> или легковесным (только сцылко в refs/tags)
17:10 < Lost> а ветка может быть только легковесной
17:10 < stanv> т.е. если я удаляю ветку, все коммиты в нее остаются ?
17:11 < Lost> как сцылко в refs/heads или в refs/remotes
17:12 < Lost> если на эти коммиты есть какие-либо другие сцылки, то не удалятся
17:12 < Lost> и даже если нету - коммиты удалятся только после git-prune
  < Lost> до гит-пруне даже есть шанс их обратно восстановить
  < lioka> Lost: а каг ?
17:16  * lioka как-то грохнул origin, было печально
17:17 < Lost> lioka: git-lost-found
17:17  * lioka так и думал

< vvk> stanv_: v@version@:postfix - это указание взять директорию postfix из тэга v@version@ и сделать дифф с директорией postfix из текущего бранча
15:10 < stanv_> ок, а что такое текущий бранч для gear ?
15:10 < thresh> тот, в котором .gear-rules
15:10 < stanv_> во
15:11 < Lost> непрально
15:11 < stanv_> а я хочу задать не текущий бранч
15:11 < Lost> нету для геара никакого текущего бранча
15:11 < Lost> и не было никогда
15:11 < Lost> есть объект-коммит, из которого все собирается
15:12 < Lost> у него есть ассоциированное дерево
15:12 < Lost> вот из этого дерева и берется
15:12 < stanv_> diff: v@version@:postfix postfix
15:12 < stanv_> что такое второй "postfix" ?
15:13 < Lost> stanv_: diff: v@version@:postfix fixes-v@version@:postfix
15:13 < stanv_> fixes-v@version@ - я такого тега не создавал 
15:14 < vvk> stanv_: второй postfix это директория для diff-а из текущего "объекта-коммита" (ц)
15:14 < Lost> stanv_: дык а что ты хочешь задавать? дифф между чем и чем?
15:15 < stanv_> между ветками. одна ветка одно сосотояние каталога, друга - другое состояние
15:16 < stanv_> текущий "объекта-коммит" существует всегда ? даже когда я сделал clone из git.alt ?
15:16 < Lost> нельзя между ветками
15:16 < Lost> можно между тегами
15:16 < Lost> ветки сегодня одни, завтра другие
15:17 < stanv_> логично
15:17 < stanv_> а если коммиты удаляются ?
15:17 < Lost> ну тогда получается что из такого репозитория нельзя собрать пакет
15:19 < stanv_> опять думать, я вот думаю, репозиторий на git.alt он же должен быть построен так что можно было бы собрать пакет любого сторай версии и любого 
                старого релиза? 
15:19 < stanv_> а почти все репоизитории этого не позволяют :( хы-хы
15:20 < Lost> stanv_: коммиты удаляются если 1) на них нету ссылок из refs/*
15:20 < Lost> и 2) был выполнен git-prune или git-gc --prune
15:21 < Lost> насколько я знаю, на git.alt выполняется git-gc без --prune
15:21 < Lost> итого - коммиты залитые туда - удаляться не будут никогда
15:22 < stanv_> блин, фигня какая-то :( не понимаю как привязать релиз пакета к состоянию репозитория
15:23 < Lost> что тебе непонятно то?
15:32 < stanv_> это же анриал вытянуть из git.alt и сказать собирика мне пакет с alt1, когда уже состояние репозитрия на git.alt для пакета alt7
15:32 < thresh> да
15:33 < swi> stanv_: а в rpm по другому?
15:33 < stanv_> swi, конечно нет :)
15:34 < swi> ну
15:35 < thresh> можно же
15:35 < thresh> по тэгу, не?
15:35 < swi> если тег не спуржился уже
15:35 < stanv_> thresh: глобал тег ?
15:35 < Lost> stanv_: в смысле анриал?
15:35 < Lost> stanv_: как раз таки не анриал, а очень даже реально должно быть
15:35 < swi> stanv_: шо ты гонишь.. я в одном репо делал три версии пакета
15:36 < thresh>   kernel-modules-nvidia-ovz-smp: PreDepends: kernel-image-ovz-smp (= 2.6.18-alt15) but 2.6.18-alt17 is to be installed
15:36 < thresh> мля
15:36 < stanv_> а, жесть... если я попрошу показать
15:36 < stanv_> не, забейте
15:36 < stanv_> буду думать
15:36 < swi> теги и бранчи думаю тебя спасут
15:36 < Lost> stanv_: там все сделано так, чтобы можно было и старые версии собирать, и новые
15:37 < stanv_> покажи такой пакет :)
15:37 < Lost> в частности, требование мержить все теги, которые перечислены в .gear-rules, в тот коммит, из которого собирается
15:37 < Lost> stanv_: любой репо возьми
15:38 < stanv_> т.е. ты предлагаешь отслеживать лог для .spec и когда был коммит для изменения Release собирать старый пакет ?
15:39 < Lost> stanv_: нет
15:39 < Lost> я предлагаю делать теги по %version-%release
15:39 < Lost> и собирать из этих тегов
15:39 < Lost> ферштейн?
15:41 < stanv_> да
15:42 < Lost> ок
15:42 < Lost> посмотри например на мой пакет KoLmafia
15:42 < stanv_> ты Lost на git.alt ?
15:42 < Lost> http://git.altlinux.org/people/damir/packages/KoLmafia.git
15:43 < Lost> не, я damir@
15:43 < stanv_> а что такое base= ?
15:44 < Lost> это значит что тарбол будет собираться без директории верхнего уровня
15:47 < Lost> так апстрим распространяет, я не виноват
15:49 < Lost> а, кстати. я наврал что репозиторий будет несобираемым
15:49 < Lost> если коммиты удалятся
15:49 < stanv_> почему?
15:49 < Lost> они не могут удалиться, потому что они смержены в тот коммит, из которого собирается
15:50 < stanv_> т.е. неможно удалить коммит который посерединке
15:50 < Lost> да
15:51 < Lost> то есть мерж в коммит где лежат gear-rules, это гарантия того, что все теги никуда не денутся
15:52 < stanv_> АААА
15:52 < stanv_> а мерж - это еще один коммит ?
15:52 < stanv_> глобальный ?
15:53 < Lost> блин, надо уже писать новую часть git guts
15:53 < stanv_> можно в ветке кучу маленьких коммитов, потом все смержить, потом удалить все маленькие коммиты ?
15:53 < Lost> а то блин люди элементарных вещей не понимают
15:53 < Lost> stanv_: нельзя удалять коммиты
15:53 < Lost> можно лишь убрать на них все ссылки
15:53 < stanv_> даже если они смержины ?
15:53 < Lost> тогда они удалятся при вызове git-prune
15:53 < Lost> операция merge - это ссылка
15:54 < Lost> когда ты делаешь merge другого коммита, ты делаешь в своей ветке ссылку на этот коммит
15:54 < stanv_> а, понятно
15:54 < Lost> и теперь пока твоя ветка жива, тот коммит тоже будет жить
 stanv_> понял
15:55 < Lost> ну или точнее, пока на этот merge-коммит хоть кто-то еще ссылается
15:55 < hiddenman_> никто миксер не подскажет, который бы видел появляющиеся и исчезающие устройства? kmix тупой
15:55 < stanv_> и базируется на этом merge-коммите другой коммит ?
15:55 < stanv_> *или
< Lost> stanv_: ну это и есть "кто-то еще ссылается"
15:56 < Lost> да
15:56 < Lost> или тег
15:56 < Lost> или ветка
15:56 < stanv_> круто
15:58 < Lost> гит - это база объектов, связанных между собой ссылками
15:58 < Lost> к ней есть т.н. внешние ссылки
15:58 < Lost> они все лежат в .git/refs и .git/HEAD
15:59 < Lost> git-prune берет все внешние ссылки (ветки и теги) и смотрит на что они ссылаются
15:59 < sadeness_> у нас кроме Lost кто-нить в git разобрался?
15:59 < Lost> ну типа тег ссылается на коммит, коммит на дерево и другие коммиты, дерево на блобы и другие деревья

17:25 < Lost> я тебе еще больше скажу - можно сделать gitk --all -- /path/to/file чтобы посмотреть коммиты, изменяющие этот файл

13:57 < stanv_> Lost: 15:39 < Lost> я предлагаю делать теги по %version-%release
13:58 < stanv_> это на код апстрима, а на модифицированный код какой тег ставить ?
14:03 < Lost> stanv_: сам ты на код апстрима
14:04 < Lost> какой у апстрима %release?
14:04 < stanv_> а
14:04 < stanv_> точно
14:04 < Lost> я на апстрим ставлю %name-%version
14:04 < stanv_> не хочу ставить тег на ветку куда приложены патчи вида  %version-%release
14:05 < stanv_> так как release может изменится, а патчи остаться теже, не изменясь совсем
14:05 < stanv_> (тег на код с изменениями а не на ветку)
14:06 < Lost> stanv_: теги можно двигать
14:06 < stanv_> а! переименовывать ?
14:06 < Lost> переставлять на другие коммиты
14:06 < stanv_> круто
14:07 < stanv_> аффигенно
14:11 < Lost> причем если ты двигаешь "вверх по дереву" - то гит даже ругаться не будет
14:11 < Lost> просто тупо обновит
14:12 < Lost> а если переставляешь куда-то на другую ветку, то когда делаешь git-push, придется еще -f указывать.
14:12 < stanv_> и когда я буду говорить push он сдвинет все на удаленом рипозитории тоже ?
14:12 < Lost> да
14:13 < Lost> если ты говоришь push --tags
14:18 < Lost> stanv_: ну? что непонятно?
14:19 < stanv_> непонятно
14:19 < Lost> stanv_: ты забыл этот тег замержить в мастер?
14:19 < stanv_> м :(
14:19 < stanv_> дальше не понимаю
14:19 < stanv_> я создал тег
14:19 < stanv_> а что еще ?
14:20 < Lost> мержить в мастер надо
14:20 < Lost> точнее туда, где у тебя .gear-rules валяеццо
14:20 < stanv_> зачем ?
14:21 < stanv_> не понимаю зачем :(
14:23 < stanv_> так есть же тег, пока есть тег - коммиты не потеряются
14:23 < Lost> stanv_: а как только тег удалят, что будет?
14:23 < Lost> stanv_: в чем в общем проблема-то?
14:23 < stanv_> не хочу заливать ветку patches в ветку srpm
14:26 < Lost> stanv_: тебе не надо ветку srpm
14:26 < Lost> плюс еще можно git-merge -s ours
14:27 < stanv_> Lost: ну ок, можно еще и git pull -s ours . patches
14:27 < stanv_> но зачем :( ? я не понимаю, зачем ?
14:34 < Lost> stanv_: я ж тебе объяснил
14:35 < stanv_> Lost: я тег честное слово не собирался никогда удалять
14:37 < stanv_> тогда если следовать этой мысли в master должны быть состояния 1.апстрим + 2.апстрим+патчи
15:04 < Lost> stanv_: я не знаю что там у тебя в master. у меня там - запачченная по самые помидоры версия
15:05 < stanv_> а код апстрима как хранится ?
15:07 < Lost> в отдельной ветке
15:07 < Lost> и мержится в master
15:07 < stanv_> т.е. все мержится в master?
15:09 < Lost> да
15:09 < Lost> ты посмотрел KoLmafia?
15:10 < stanv_> да
15:11 < Lost> и ничего не понял, так?
15:13 < stanv_> я как понял все нужно мержить в мастер
15:13 < stanv_> только зачем не понял
15:14 < stanv_> и не понял как делать merge в мастер когда обновился апстрим... там же будет кучу нестыковок
15:14 < Lost> для того, чтобы можно было собирать старые версии
15:15 < stanv_> для старых версие есть теги
15:15 < Lost> stanv_: ты мержи upstream в patches, а потом patches в master
15:15 < Lost> stanv_: теги можно двигать, ку-ку
15:15 < stanv_> ептить, ладно понял, все, вопросов больше нету :)
15:17 < Lost> мержить в мастер надо для воспроизводимости
15:17 < Lost> вот и все

stanv_> а что означает стратегия ours при pull ?
17:08 < AMorozov> stanv_: при pull ?
17:08 < AMorozov> Не то же самое, что при merge ?
17:08 < stanv_> ну ладно, что она означает 6)
17:08 < stanv_> :)
17:08 < AMorozov> То есть, насколько я помню, pull == fetch <remote> + merge <remote>
17:09 < AMorozov> Это фэйковый, виртуальный коммит.
17:09 < Lost> stanv_: значит что ничего не меняется, но ветки оказываются смержеными
17:09 < AMorozov> То есть, сорцы не изменяются вообще, а дерево ветки как-бы мержатся, судя по истории.
17:10 < Lost> AMorozov: мержится только история, без деревьев
17:10 < AMorozov> Ну.
17:10 < AMorozov> А я чего сказал? ;-)
17:10 < stanv_> ы :( не понимаю, а где почитать можно как это происходит ? и его смысл ?
17:10 < Lost> stanv_: man git-merge
17:11 < AMorozov> stanv_: смысл - например, ты хочешь сказать, что ты смержил изменения из какой-то ветки, хотя они тебе даром не нужны :-)
17:12 < Lost> stanv_: это все нужно для манипуляции с историей

< stanv_> как посмотреть SHA1 тага ?
15:42 < Lost> git-rev-parse имя тега
< stanv_> Lost: http://paste.org.ru/?tkiafm
16:09 < stanv_> чего-то я не могу привязать тег к комиту который я хочу :(
16:11 < Lost> stanv_: ты смотришь SHA1 тега
16:11 < Lost> а не SHA1 коммита
16:11 < Lost> ку-ку :)
16:12 < Lost> если хочешь посмотреть SHA1 коммита, на который указывает тег - надо делать git-rev-parse тег^{commit}
16:12 < Lost> то есть типа так: git-rev-parse jackit-0.103.0^{commit}

16:25 < stanv_> как сказать чтобы gear-update-tag добавил SHA1 коммита а не тега ?
16:26 < Lost> stanv_: ты чего, упал чтоли?
16:26 < Lost> зачем?
16:26 < Lost> stanv_: в принципе конечно можно
16:26 < Lost> stanv_: делай git-tag без -s
16:26 < Lost> будет легкий тег, без объекта
16:27 < Lost> для него только SHA1 коммита записывается
16:27 < Lost> только такие теги нельзя на git.alt заливать

16:29 < stanv_> Lost: а что такое merge ?
16:29 < Lost> stanv_: merge - это слияние двух веток и образования т.н. merge-commit
16:29 < Lost> stanv_: родителями которого являются топ-коммиты в сливающихся ветках
16:30 < Lost> stanv_: что при этом происходит с деревьями, которые были прикреплены к каждому коммиту - зависит от стратегии слияния
16:31 < Lost> можно брать либо то дерево, либо другое
16:31 < Lost> либо как-то их комбинировать
16:31 < stanv_> а можно только чтоб в дереве были полностью модифицированные файлы ?
16:31 < Lost> а что значит "полностью модифицированные"?
16:32 < stanv_> отображение только тех файлов, которые были затронуты (которые несут отличия между ветками)
16:33 < Lost> stanv_: все равно не понял что ты хочешь получить
16:34 < Lost> stanv_: что значит "отображение"?
16:35 < stanv_> Lost: существование
16:36 < Lost> stanv_: ты в терминах деревьев объясни
16:37 < stanv_> Lost: что дерево состояло только из файлов, которые иные в ветке с которой мержили
16:37 < stanv_> не понимаю что такое merge
16:37 < stanv_> понимаю что тако патч
16:39 < evyscr> stanv_: в терминах svn: у тебя есть локальная копия файла, ты её изменил, делаешь апдейт, а файл обновился. svn попытается применить твои изменения к обновлённому файлу.
16:42 < stanv_> понимаю
16:42 < stanv_> я не понимаю в виде чего это хранится
16:42 < stanv_> раз не в дифах
16:42 < stanv_> то в чем
16:49 < Lost> stanv_: читай мой жж
16:49 < Lost> stanv_: там все понятно в чем хранится
16:49 < Lost> в деревьях хранится
16:50 < stanv_> Lost: мож дать ссылку ?
16:54 < Lost> stanv_: los-t.livejournal.com