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 < Lost> AMorozov: Y 17:09 < AMorozov> То есть, сорцы не изменяются вообще, а дерево ветки как-бы мержатся, судя по истории. 17:09 < Lost> AMorozov: по executable stack - man ld :) 17:10 -!- |xenonex_| [n=xenonex@85.195.161.243.satgate.net] has joined #altlinux 17:10 < Lost> AMorozov: мержится только история, без деревьев 17:10 < AMorozov> Ну. 17:10 -!- |xenonex_| [n=xenonex@85.195.161.243.satgate.net] has quit [Remote closed the connection] 17:10 < AMorozov> А я чего сказал? ;-) 17:10 < stanv_> ы :( не понимаю, а где почитать можно как это происходит ? и его смысл ? 17:10 < AMorozov> А какого хрена он по умолчанию проставился на FC7 17:10 < Lost> stanv_: man git-merge 17:11 < AMorozov> stanv_: смысл - например, ты хочешь сказать, что ты смержил изменения из какой-то ветки, хотя они тебе даром не нужны :-) 17:11 < greg_f> куда надо класть видео кодеки win32? 17:11 < AMorozov> greg_f: в /dev/null ? 17:12 < Lost> stanv_: это все нужно для манипуляции с историей
Powered by WackoWiki R4.2