Michael Shigorin пишет: > Здравствуйте. > Переношу в devel@ из ltsp-server@; предыстория: > http://lists.altlinux.org/pipermail/ltsp-server/2008-January/000209.html > http://lists.altlinux.org/pipermail/ltsp-server/2008-January/000210.html > http://lists.altlinux.org/pipermail/ltsp-server/2008-January/000211.html > > Просьба по возможности и осмысленности обсуждать в devel@. > > > On Fri, Jan 25, 2008 at 11:09:54AM +0300, Eugene Prokopiev wrote: >>> Кстати, Миш, а не напишешь пошаговую шпаргалку по >>> использованию git и взаимодействию c апстримом в лице >>> boyarsh@ - очень хороший и простой пример получается :) > > Эээ... можно попробовать, только разумно сперва бы зачистить > и смержить всё-таки. > > Если хочешь, можешь пока потренироваться на мне как на апстриме > с ltsp-cd ;) > >> Примерный план: > > 0. http://www.kernel.org/pub/software/scm/git/docs/everyday.html > http://www.kernel.org/pub/software/scm/git/docs/tutorial.html > http://wiki.sisyphus.ru/devel/git > http://lwn.net/Articles/245678/ > >> 1. Клонируем чужое дерево - >> git-clone git.alt:/people/boyarsh/packages/mkimage-profiles-ltsp.git > > Да. (только s/ltsp/desktop/ или s/boyarsh/mike/ :) > >> 2. Делаем бранч (точно бранч? как?) > > git checkout -b enp/ltsp-cd > > Достать существующий бранч -- git checkout master > > Посмотреть, какие есть -- git branch, git branch -r (+remotes) > > Затащить к себе ремотный бранч (ужас, какой сурж, но "удалённый" > ещё прозвучит :) [заодно как не через ssh, а по git://] -- > > git fetch git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop.git 4.0.1:4.0.1 > > или (btw спасибо за показ "на пальцах" raorn@) > > git fetch http://git.altlinux.org/people/mike/packages/mkimage-profiles-ltsp.git mike/ltsp:ltsp > > (указывается имя бранча "там" и как его звать "тут") > > Да, фетчить в тот бранч, где стоишь -- не стоит; лучше checkout > какой-то другой, сперва (бывали недоразумения). Ну или хотя бы > cd . потом. Хорошо бы кто разъяснил, ldv@ в последний раз просто > подтвердил мои неосознанные опасения из практики, что "так лучше > не делать". > > Удалить -- git branch -D tmp/test > >> в нем что-то правим, коммитим (git-commit) > > Обычно -a, но зависит; если не -a, то поправленные файлы > приходится добавлять в индекс при помощи git add (git status > подскажет). См. tutorial подробнее. > > Если коммит надо бы поправить (чтоб не разводить при быстром > обнаружении ляпа кучу мелких "упс, а тут ещё такая штука") -- > можно git commit -a --amend, только если тот коммит уже > публиковался, то смержиться с новым без отката на предыдущий > (общий) у тех, кто успел его забрать -- не выйдет. > > Бишь "правило большого пальца" -- семь раз amend, один раз push. > >> выпекаем rpm/srpm (gear -v --hasher -- hsh ~/hasher/) > > Это для профиля как раз дело последнее, если только его не > требуется включить в выпекаемый ISO... > >> 3. Видим, что в апстриме появилось что-то новенькое, делаем >> git-pull и git-merge (в какой последовательности? с какими >> параметрами?) > > git pull в том же репо/бранче, который ты clone'ировал -- вытянет > и смержит изменения в апстриме. > > git pull . master смержит изменения в бранче master в тот бранч, > где сейчас стоишь. > > git merge я не использую. > > git-fetch тоже мержит, если целевой бранч уже был. Но только в том случаи, если уже существующий целевой бранч прямой предок того что fetch`им. Если нет -- то ругнётся (если сказать git-fetch -f -- затрёт). > >> 4. Выпекам новый rpm/srpm еще раз > > См. выше. > > Я обычно вместо этого делаю rsync профиля (вместе с .git) туда, > где происходит сборка; надо будет посмотреть повнимательней на > ./configure --with-outdir, но есть подозрение, что от .work/ в > профиле пока не избавиться никак, а в гитовом репо они мне совсем > не нужны. > > Чтоб rsync --delete отработал нормально, сперва "там, где" надо > make distclean какой. В общем, пока не совсем удобно. > >> Еще интересен сценарий, в котором апстрим решит чего-то у тебя >> позаимствовать ... > > Так а что, fetch'нет и pull'нет или на'cherrypick'ает :) > -- С уважением. Алексей.