[Comm] git and packaging

[Comm] git and packaging

[Andriy Dobrovol`s`kii]

Hi,
После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
Почитал документацию. Вижу, что гит это просто ещё одна CVS. Значит
сам по себе он никак упростить работу по упаковке не может. Наоборот,
кроме знаний необходимых для упаковки нужно ещё изучить команды
системы управлениями версиями.
Насколько я понял, гит-альт это уже не чисто гит. А гит с надстройкой
для управления сборкой пакетов на основании исходников лежащих в
гит-альт. Значит нужно ещё и запомнить команды управления сборкой.
Опять упрощения не заметно...
Работать с исходниками, в том числе спеком, прямо на гит-альт наверно
можно. Если есть соответствующий канал. Однако до команды на
"официальную" сборку нужно бы убедиться, что уже пора. Значит нужно
надцать раз прогнать тестовые сборки. Прямо на сборочных серверах? Или
таки это нужно делать дома?
Если дома, значит нужна вся сборочная инфраструктура. ~/RPM rpm
hasher... Плюс какалог с гитом. Или нет?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Андрей Черепанов]

16 марта 2009, Andriy Dobrovol`s`kii написал(а):
> Hi,
> После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
> Почитал документацию. Вижу, что гит это просто ещё одна CVS. Значит
> сам по себе он никак упростить работу по упаковке не может. Наоборот,
> кроме знаний необходимых для упаковки нужно ещё изучить команды
> системы управлениями версиями.
> Насколько я понял, гит-альт это уже не чисто гит. А гит с надстройкой
> для управления сборкой пакетов на основании исходников лежащих в
> гит-альт. Значит нужно ещё и запомнить команды управления сборкой.
> Опять упрощения не заметно...
> Работать с исходниками, в том числе спеком, прямо на гит-альт наверно
> можно. Если есть соответствующий канал. Однако до команды на
> "официальную" сборку нужно бы убедиться, что уже пора. Значит нужно
> надцать раз прогнать тестовые сборки. Прямо на сборочных серверах? Или
> таки это нужно делать дома?
Если есть репозиторий, то сборку можно и локально через gear-hsh делать. Ничем 
от hasher не отличается кроме того, что пропускается лишняя стадия создания 
src.rpm.

> Если дома, значит нужна вся сборочная инфраструктура. ~/RPM rpm
> hasher... Плюс какалог с гитом. Или нет?
Смотри: вместо помойки в ~/RPM/SOURCE и ~/RPM/SPECS у тебя будет по отдельному 
каталогу для пакета. С возможностью оперировать исходниками (например, делать 
патчи) уже в раскрытом виде, не мучаясь с их поиском и распаковкой. Плюс 
коммиты, как фиксация изменений. После этого потеря данных не страшна, если 
git запушить (git push) на сервер. Трафик в этом случае минимальный, а данные 
будут в порядке.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/16 Андрей Черепанов <cas@altlinux.ru>:
> 16 марта 2009, Andriy Dobrovol`s`kii написал(а):
>> Hi,
>> После горячей дискуссии по поводу бэкпотров решился "поковырять" гит.
>> Почитал документацию. Вижу, что гит это просто ещё одна CVS. Значит
>> сам по себе он никак упростить работу по упаковке не может. Наоборот,
>> кроме знаний необходимых для упаковки нужно ещё изучить команды
>> системы управлениями версиями.
>> Насколько я понял, гит-альт это уже не чисто гит. А гит с надстройкой
>> для управления сборкой пакетов на основании исходников лежащих в
>> гит-альт. Значит нужно ещё и запомнить команды управления сборкой.
>> Опять упрощения не заметно...
>> Работать с исходниками, в том числе спеком, прямо на гит-альт наверно
>> можно. Если есть соответствующий канал. Однако до команды на
>> "официальную" сборку нужно бы убедиться, что уже пора. Значит нужно
>> надцать раз прогнать тестовые сборки. Прямо на сборочных серверах? Или
>> таки это нужно делать дома?
> Если есть репозиторий, то сборку можно и локально через gear-hsh делать. Ничем
> от hasher не отличается кроме того, что пропускается лишняя стадия создания
> src.rpm.
>
Ну, не думаю, что кто-нибудь отдельно создает src.rpm-ы... А вот
заменит ли gear-hsh процедуру инициализации локального hasher?
>> Если дома, значит нужна вся сборочная инфраструктура. ~/RPM rpm
>> hasher... Плюс каталог с гитом. Или нет?
> Смотри: вместо помойки в ~/RPM/SOURCE и ~/RPM/SPECS у тебя будет по отдельному
> каталогу для пакета.
Отдельные каталоги это понятно, но и структура  ~/RPM/SOURCE и
~/RPM/SPECS не кажется мне помойкой. :)
>С возможностью оперировать исходниками (например, делать
> патчи) уже в раскрытом виде, не мучаясь с их поиском и распаковкой.
Да я и так знал где они лежат... ;) А закачивать авторские исходники
нужно в любом случае. Выигрыш по трафику только если у автора тоже гит
и структура своего гита сразу правильно продумана...
>Плюс
> коммиты, как фиксация изменений. После этого потеря данных не страшна, если
> git запушить (git push) на сервер. Трафик в этом случае минимальный, а данные
> будут в порядке.
>
Вот тут самый большой вопрос. Если я делаю только изменения в спеке
добиваясь собираемости, на кой мне комиты? И весь связанный с ними
оверхед? (Про полезность CVS для реальных разработчиков я в курсе.) И,
наконец, пушить нужно куда-то... А куда? Если я ещё не в команде... А
насобачившись собирать пакеты без оверхеда, захочу ли я грузить себя
им только ради вступления в команду?..
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Андрей Черепанов]

16 марта 2009, Andriy Dobrovol`s`kii написал(а):
> > Если есть репозиторий, то сборку можно и локально через gear-hsh делать.
> > Ничем от hasher не отличается кроме того, что пропускается лишняя стадия
> > создания src.rpm.
>
> Ну, не думаю, что кто-нибудь отдельно создает src.rpm-ы... А вот
> заменит ли gear-hsh процедуру инициализации локального hasher?
А как запускать в хэшере? Я раньше, до gear, создавал. Сборка локально через 
gear и через hasher отличается только входными данными. Настройка та же.

> >> Если дома, значит нужна вся сборочная инфраструктура. ~/RPM rpm
> >> hasher... Плюс каталог с гитом. Или нет?
> >
> > Смотри: вместо помойки в ~/RPM/SOURCE и ~/RPM/SPECS у тебя будет по
> > отдельному каталогу для пакета.
>
> Отдельные каталоги это понятно, но и структура  ~/RPM/SOURCE и
> ~/RPM/SPECS не кажется мне помойкой. :)
Эти два каталога имеют тенденцию быстро заполняться и организовывают помойку.

> >С возможностью оперировать исходниками (например, делать
> > патчи) уже в раскрытом виде, не мучаясь с их поиском и распаковкой.
>
> Да я и так знал где они лежат... ;) А закачивать авторские исходники
> нужно в любом случае. Выигрыш по трафику только если у автора тоже гит
> и структура своего гита сразу правильно продумана...
gear-update позволяет залить новый тарболл и в git будут только изменения 
кода, а не исходники целиком.

> >Плюс
> > коммиты, как фиксация изменений. После этого потеря данных не страшна,
> > если git запушить (git push) на сервер. Трафик в этом случае минимальный,
> > а данные будут в порядке.
>
> Вот тут самый большой вопрос. Если я делаю только изменения в спеке
> добиваясь собираемости, на кой мне комиты? И весь связанный с ними
> оверхед? (Про полезность CVS для реальных разработчиков я в курсе.) И,
> наконец, пушить нужно куда-то... А куда? Если я ещё не в команде... А
> насобачившись собирать пакеты без оверхеда, захочу ли я грузить себя
> им только ради вступления в команду?..
1. Коммиты для сохранения результатов правки .spec
2. Возможность правки кода для быстрого получения патчей (после чего изменения 
откатываются)
3. Простое бэкпортирование через подписанные теги

Оверхед как раз резко уменьшается при сборке > 1 пакета. И никто не мешает 
хранить локальный git и собирать из него через gear.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Motsyo Gennadi aka Drool]

Андрей Черепанов пишет:
> А как запускать в хэшере? Я раньше, до gear, создавал. Сборка локально через 
> gear и через hasher отличается только входными данными. Настройка та же.

	Я не создаю src.rpm для хашера. Мне хватает hsh-shell.

Re: [Comm] git and packaging

[Андрей Черепанов]

17 марта 2009, Motsyo Gennadi aka Drool написал(а):
> Андрей Черепанов пишет:
> > А как запускать в хэшере? Я раньше, до gear, создавал. Сборка локально
> > через gear и через hasher отличается только входными данными. Настройка
> > та же.
>
> 	Я не создаю src.rpm для хашера. Мне хватает hsh-shell.
Ты жесток. Это нечистая сборка.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/16 Андрей Черепанов <cas@altlinux.ru>:
> 16 марта 2009, Andriy Dobrovol`s`kii написал(а):
>> > Если есть репозиторий, то сборку можно и локально через gear-hsh делать.
>> > Ничем от hasher не отличается кроме того, что пропускается лишняя стадия
>> > создания src.rpm.
>>
>> Ну, не думаю, что кто-нибудь отдельно создает src.rpm-ы... А вот
>> заменит ли gear-hsh процедуру инициализации локального hasher?
> А как запускать в хэшере? Я раньше, до gear, создавал. Сборка локально через
> gear и через hasher отличается только входными данными. Настройка та же.
>
А... Теперь понял о чем Вы. А каков ответ на вопрос?
>> >> Если дома, значит нужна вся сборочная инфраструктура. ~/RPM rpm
>> >> hasher... Плюс каталог с гитом. Или нет?
>> >
>> > Смотри: вместо помойки в ~/RPM/SOURCE и ~/RPM/SPECS у тебя будет по
>> > отдельному каталогу для пакета.
>>
>> Отдельные каталоги это понятно, но и структура  ~/RPM/SOURCE и
>> ~/RPM/SPECS не кажется мне помойкой. :)
> Эти два каталога имеют тенденцию быстро заполняться и организовывают помойку.
>
И да и нет... Но, мысль понятна.
>> >С возможностью оперировать исходниками (например, делать
>> > патчи) уже в раскрытом виде, не мучаясь с их поиском и распаковкой.
>>
>> Да я и так знал где они лежат... ;) А закачивать авторские исходники
>> нужно в любом случае. Выигрыш по трафику только если у автора тоже гит
>> и структура своего гита сразу правильно продумана...
> gear-update позволяет залить новый тарболл и в git будут только изменения
> кода, а не исходники целиком.
>
Ну, нужно значит дальше смотреть. Хотя для упаковщика польза
сомнительная. Сколько пересобирал пакеты ради новых версий, ни разу
старые тарболы не понадобились...
Повторюсь, что про пользу СКВ для разработчика я ни разу не сомневаюсь.
>> >Плюс
>> > коммиты, как фиксация изменений. После этого потеря данных не страшна,
>> > если git запушить (git push) на сервер. Трафик в этом случае минимальный,
>> > а данные будут в порядке.
>>
>> Вот тут самый большой вопрос. Если я делаю только изменения в спеке
>> добиваясь собираемости, на кой мне комиты? И весь связанный с ними
>> оверхед? (Про полезность CVS для реальных разработчиков я в курсе.) И,
>> наконец, пушить нужно куда-то... А куда? Если я ещё не в команде... А
>> насобачившись собирать пакеты без оверхеда, захочу ли я грузить себя
>> им только ради вступления в команду?..
> 1. Коммиты для сохранения результатов правки .spec
Это понятно. Я спрашиваю про полезность таких комитов...
> 2. Возможность правки кода для быстрого получения патчей (после чего изменения
> откатываются)
Тут, как я понимаю, упаковщику придется основательно учить команды СКВ?..
> 3. Простое бэкпортирование через подписанные теги
>
Это если упаковщику оно надо и он член команды. А если нет?
> Оверхед как раз резко уменьшается при сборке > 1 пакета. И никто не мешает
> хранить локальный git и собирать из него через gear.
>
Ну вот я и упражняюсь пока с таким гитом. Теперь вот оказывается нужен
ещё и gear... Зависимость оверхеда от количества пакетов не понял. То,
что уменьшается его удельный вес в общем объеме работы?
>
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Андрей Черепанов]

17 марта 2009, Andriy Dobrovol`s`kii написал(а):
> 2009/3/16 Андрей Черепанов <cas@altlinux.ru>:
> > 16 марта 2009, Andriy Dobrovol`s`kii написал(а):
> >> > Если есть репозиторий, то сборку можно и локально через gear-hsh
> >> > делать. Ничем от hasher не отличается кроме того, что пропускается
> >> > лишняя стадия создания src.rpm.
> >>
> >> Ну, не думаю, что кто-нибудь отдельно создает src.rpm-ы... А вот
> >> заменит ли gear-hsh процедуру инициализации локального hasher?
> >
> > А как запускать в хэшере? Я раньше, до gear, создавал. Сборка локально
> > через gear и через hasher отличается только входными данными. Настройка
> > та же.
>
> А... Теперь понял о чем Вы. А каков ответ на вопрос?
Я думал, что единственный способ нормально запустить в хэшере - это скормить 
ему src.rpm. Drool подсказал, что можно и через hsh-shell, но IMHO, это 
грязный хак. Так что приходится делать src.rpm.

> >> >С возможностью оперировать исходниками (например, делать
> >> > патчи) уже в раскрытом виде, не мучаясь с их поиском и распаковкой.
> >>
> >> Да я и так знал где они лежат... ;) А закачивать авторские исходники
> >> нужно в любом случае. Выигрыш по трафику только если у автора тоже гит
> >> и структура своего гита сразу правильно продумана...
> >
> > gear-update позволяет залить новый тарболл и в git будут только изменения
> > кода, а не исходники целиком.
>
> Ну, нужно значит дальше смотреть. Хотя для упаковщика польза
> сомнительная. Сколько пересобирал пакеты ради новых версий, ни разу
> старые тарболы не понадобились...
> Повторюсь, что про пользу СКВ для разработчика я ни разу не сомневаюсь.
А они остаются в истории git. Речь идёт про новые тарболлы. Кстати, можно из 
апстрима брать сразу из CVS, SVN и, разумеется, git, а не скачивать тарболлы и 
мучатся с их натягиванием на git.

> >> >Плюс
> >> > коммиты, как фиксация изменений. После этого потеря данных не страшна,
> >> > если git запушить (git push) на сервер. Трафик в этом случае
> >> > минимальный, а данные будут в порядке.
> >>
> >> Вот тут самый большой вопрос. Если я делаю только изменения в спеке
> >> добиваясь собираемости, на кой мне комиты? И весь связанный с ними
> >> оверхед? (Про полезность CVS для реальных разработчиков я в курсе.) И,
> >> наконец, пушить нужно куда-то... А куда? Если я ещё не в команде... А
> >> насобачившись собирать пакеты без оверхеда, захочу ли я грузить себя
> >> им только ради вступления в команду?..
> >
> > 1. Коммиты для сохранения результатов правки .spec
>
> Это понятно. Я спрашиваю про полезность таких комитов...
а) Откат в случае ошибки на работающую версию
б) хранение изменений: что и зачем менял

> > 2. Возможность правки кода для быстрого получения патчей (после чего
> > изменения откатываются)
>
> Тут, как я понимаю, упаковщику придется основательно учить команды СКВ?..
Не-а! Просто 
1. меняешь сам код
2. собираешь через gear-hsh $TMP --commit (временный коммит на момент сборки)
3. Если всё хорошо, а код хочется оставить нетронутым, то
git diff > file.patch
4. откатываешь изменения в основном коде:
git reset --soft HEAD^
4. добавляшь патч в спек, заодно меняешь changelog
5. git add . && gear-commit -a
У тебя сразу подставляется в описание коммита последняя запись из changelog из 
спека.


> > 3. Простое бэкпортирование через подписанные теги
>
> Это если упаковщику оно надо и он член команды. А если нет?
А если сосед попросит сделать для 4.1 branch, а у тебя 5.0?

> > Оверхед как раз резко уменьшается при сборке > 1 пакета. И никто не
> > мешает хранить локальный git и собирать из него через gear.
>
> Ну вот я и упражняюсь пока с таким гитом. Теперь вот оказывается нужен
> ещё и gear... 
gear нужен только для локальной сборки (для проверки или сборки для личных 
целей)

> Зависимость оверхеда от количества пакетов не понял. То,
> что уменьшается его удельный вес в общем объеме работы?
Твои ~/RPM/SOURCE и ~/RPM/SPECS начинают расползаться (особенно первый, там 
всё в одном каталоге). В этой свалке искать нужные патчи становится 
утомительно, да и перепрыгивание между сборочницей (~/RPM/BUILD, иначе где 
лежат распакованные сырцы?), каталогом со спеком и каталогом с тарболлами и 
патчами сильно отнимает время.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Motsyo Gennadi aka Drool]

Андрей Черепанов пишет:
> Я думал, что единственный способ нормально запустить в хэшере - это скормить 
> ему src.rpm. Drool подсказал, что можно и через hsh-shell, но IMHO, это 
> грязный хак. Так что приходится делать src.rpm.

	Это наглый наклёп! ;) Никакой это не грязный хак, это штатная 
возможность. У меня в хашере настроен ccache, rpmmacros, rpm-utils для 
buildreq, у меня система не загрязнена *-devel пакетами. Если накосячу в 
нем что-то - сохраняю содержимое хашеровского хомяка, hsh --init и 
возвращаю на место. Я не жду, пока счежий хашер (у меня и такой есть, 
для тестового прогона) инициализируется, не втянет зависимости и не 
создаст сборочную среду. И уже внутри hsh-shell я пишу спеки, rpm -ba и 
все такое. Очень доволен.

Re: [Comm] git and packaging

[Michael Shigorin]

On Wed, Mar 18, 2009 at 12:11:31PM +0200, Motsyo Gennadi aka Drool wrote:
> Это наглый наклёп! ;) Никакой это не грязный хак, это штатная
> возможность. У меня в хашере настроен ccache, rpmmacros,
> rpm-utils для buildreq, у меня система не загрязнена *-devel
> пакетами. Если накосячу в нем что-то - сохраняю содержимое
> хашеровского хомяка, hsh --init и возвращаю на место.

Кстати, подокументировал бы.  Я вот два дня OpenSceneGraph
собирал -- из-за ерунды в %install/%files после полуторачасовой
сборки только сегодня утром добил.  Всё вспоминал про ccache,
но "ну это ж _точно_ последняя сборка!" не давало ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] git and packaging

[Motsyo Gennadi aka Drool]

Michael Shigorin пишет:
> On Wed, Mar 18, 2009 at 12:11:31PM +0200, Motsyo Gennadi aka Drool wrote:
>> Это наглый наклёп! ;) Никакой это не грязный хак, это штатная
>> возможность. У меня в хашере настроен ccache, rpmmacros,
>> rpm-utils для buildreq, у меня система не загрязнена *-devel
>> пакетами. Если накосячу в нем что-то - сохраняю содержимое
>> хашеровского хомяка, hsh --init и возвращаю на место.
> 
> Кстати, подокументировал бы.  Я вот два дня OpenSceneGraph
> собирал -- из-за ерунды в %install/%files после полуторачасовой
> сборки только сегодня утром добил.  Всё вспоминал про ccache,
> но "ну это ж _точно_ последняя сборка!" не давало ;-)

А что документировать то? Партия указала нам светлый путь, зачем кому-то 
говорить как теперь неправильно паковать, это во-первых, а во-вторых - 
hsh-shell/hsh-install - это штатная работа с хашером, а внутри хашера - 
это обычная работа как в своем домашнем окружении.

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/24 Motsyo Gennadi aka Drool <motsyo@:
> А что документировать то? Партия указала нам светлый путь, зачем кому-то
> говорить как теперь неправильно паковать, это во-первых, а во-вторых -
> hsh-shell/hsh-install - это штатная работа с хашером, а внутри хашера - это
> обычная работа как в своем домашнем окружении.
У нас же "свободный софт для свободных людей"... ;) Тем более если это
"штатная работа с хашером..."
Просто всегда приятно прочесть про эту штатную работу на "ридний мови..."
:)
Задокументируете?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Motsyo Gennadi aka Drool]

Andriy Dobrovol`s`kii пишет:
> У нас же "свободный софт для свободных людей"... ;) Тем более если это
> "штатная работа с хашером..."

Не понимаю - что можно еще документировать в хашере :)

> Просто всегда приятно прочесть про эту штатную работу на "ридний мови..."
> :)
> Задокументируете?

На родном языке? Запросто ;)

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/24 Motsyo Gennadi aka Drool <motsyo@gmail.com>:
> Andriy Dobrovol`s`kii пишет:
>>
>> У нас же "свободный софт для свободных людей"... ;) Тем более если это
>> "штатная работа с хашером..."
>
> Не понимаю - что можно еще документировать в хашере :)
>
>> Просто всегда приятно прочесть про эту штатную работу на "ридний мови..."
>> :)
>> Задокументируете?
>
> На родном языке? Запросто ;)
Возвращаюсь к "нашим баранам". Геннадий, Вы задокументировали?
:)
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Motsyo Gennadi aka Drool]

Andriy Dobrovol`s`kii пишет:
> Возвращаюсь к "нашим баранам". Геннадий, Вы задокументировали?

	Немного попустило со временем. Где документировать лучше? На altlinux.org ?

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/10/23 Motsyo Gennadi aka Drool <motsyo@gmail.com>:
> Andriy Dobrovol`s`kii пишет:
>>
>> Возвращаюсь к "нашим баранам". Геннадий, Вы задокументировали?
>
>        Немного попустило со временем. Где документировать лучше? На
> altlinux.org ?
Думаю, да.
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Michael Shigorin]

On Tue, Mar 24, 2009 at 04:28:28PM +0200, Motsyo Gennadi aka Drool wrote:
> >>Это наглый наклёп! ;) Никакой это не грязный хак, это штатная
> >>возможность. У меня в хашере настроен ccache, rpmmacros,
> >>rpm-utils для buildreq, у меня система не загрязнена *-devel
> >>пакетами. Если накосячу в нем что-то - сохраняю содержимое
> >>хашеровского хомяка, hsh --init и возвращаю на место.
> >Кстати, подокументировал бы.  Я вот два дня OpenSceneGraph
> >собирал -- из-за ерунды в %install/%files после
> >полуторачасовой сборки только сегодня утром добил.  Всё
> >вспоминал про ccache, но "ну это ж _точно_ последняя сборка!"
> >не давало ;-)
> А что документировать то? Партия указала нам светлый путь,
> зачем кому-то говорить как теперь неправильно паковать

Ой, я тебя умоляю.  hsh-shell тоже не сразу строился,
первоначально его полезность ldv@ отрицалась.  А мне работу
с ним примерно в таком режиме вон eostapets@ на пальцах
показывал, с тех пор чуть ли не каждый раз пригождается.

> это во-первых, а во-вторых - hsh-shell/hsh-install - это
> штатная работа с хашером, а внутри хашера - это обычная работа
> как в своем домашнем окружении.

И всё-таки буду благодарен, если доберёшься обрисовать чуть
подробней на вики.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

Добрый день,
2009/3/18 Андрей Черепанов <cas@>:
> А они остаются в истории git. Речь идёт про новые тарболлы. Кстати, можно из
> апстрима брать сразу из CVS, SVN и, разумеется, git, а не скачивать тарболлы и
> мучатся с их натягиванием на git.
>
Хорошо. Есть простенький гит, (ветки master и current) в который был
уложен тарбол с релизом софтины. Исходники в виде "от автора" лежат в
мастере. Вышел новый релиз. Затянул я себе свежий тарбол. В виде
tar.bz2. И как мне теперь укладывать этот новый тарбол в гит? Чтение
мана по gear-update что-то не просветило... Что подразумевается под
<subdirectory> как указать тип tar.bz2?
-t,--type=TYPE
              define source type: 'dir', 'tar', 'cpio', 'cpio.gz',  'cpio.bz2'
              or 'zip';
Тут такой отсутствует. Разбзиповывать?
Создавать новую ветку? Что-то я в куче рассуждений на нашей вики
ответа на этот простенький вопрос не нахожу...

-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Sun, Mar 22, 2009 at 07:36:24PM +0200, Andriy Dobrovol`s`kii wrote:
> Хорошо. Есть простенький гит, (ветки master и current) в который был
> уложен тарбол с релизом софтины. Исходники в виде "от автора" лежат в
> мастере. Вышел новый релиз. Затянул я себе свежий тарбол. В виде
> tar.bz2. И как мне теперь укладывать этот новый тарбол в гит? Чтение
> мана по gear-update что-то не просветило... Что подразумевается под
> <subdirectory> как указать тип tar.bz2?
> -t,--type=TYPE
>               define source type: 'dir', 'tar', 'cpio', 'cpio.gz',  'cpio.bz2'
>               or 'zip';
> Тут такой отсутствует. Разбзиповывать?

В большинстве случаев опцию -t вообще не нужно указывать - тип
определяется автоматически (вызовом file -z).  При этом tar умеет
самостоятельно определять сжатие gzip или bzip2 и вызывать
соответствующий распаковщик, а для cpio на вход нужно подавать уже
распакованные данные, поэтому для сжатых cpio введены отдельные типы,
а для tar используется один тип независимо от сжатия.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/22 Sergey Vlasov <vsu@>:
> On Sun, Mar 22, 2009 at 07:36:24PM +0200, Andriy Dobrovol`s`kii wrote:
>> Хорошо. Есть простенький гит, (ветки master и current) в который был
>> уложен тарбол с релизом софтины. Исходники в виде "от автора" лежат в
>> мастере. Вышел новый релиз. Затянул я себе свежий тарбол. В виде
>> tar.bz2. И как мне теперь укладывать этот новый тарбол в гит? Чтение
>> мана по gear-update что-то не просветило... Что подразумевается под
>> <subdirectory> как указать тип tar.bz2?
>> -t,--type=TYPE
>>               define source type: 'dir', 'tar', 'cpio', 'cpio.gz',  'cpio.bz2'
>>               or 'zip';
>> Тут такой отсутствует. Разбзиповывать?
>
> В большинстве случаев опцию -t вообще не нужно указывать - тип
> определяется автоматически (вызовом file -z).  При этом tar умеет
> самостоятельно определять сжатие gzip или bzip2 и вызывать
> соответствующий распаковщик, а для cpio на вход нужно подавать уже
> распакованные данные, поэтому для сжатых cpio введены отдельные типы,
> а для tar используется один тип независимо от сжатия.
>
Спасибо. С типом понятно. Это было бы хорошо в ман добавить... Пусть
не всё. Но хоть про необязательность указания типа для неперечисленных
случаев.
А что такое <subdirectory>?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

В Вск, 22/03/2009 в 21:19 +0200, Andriy Dobrovol`s`kii пишет:
> 2009/3/22 Sergey Vlasov <vsu@>:
> > On Sun, Mar 22, 2009 at 07:36:24PM +0200, Andriy Dobrovol`s`kii wrote:
> >> Хорошо. Есть простенький гит, (ветки master и current) в который был
> >> уложен тарбол с релизом софтины. Исходники в виде "от автора" лежат в
> >> мастере. Вышел новый релиз. Затянул я себе свежий тарбол. В виде
> >> tar.bz2. И как мне теперь укладывать этот новый тарбол в гит? Чтение
> >> мана по gear-update что-то не просветило... Что подразумевается под
> >> <subdirectory> как указать тип tar.bz2?
> >> -t,--type=TYPE
> >>               define source type: 'dir', 'tar', 'cpio', 'cpio.gz',  'cpio.bz2'
> >>               or 'zip';
> >> Тут такой отсутствует. Разбзиповывать?
> >
> > В большинстве случаев опцию -t вообще не нужно указывать - тип
> > определяется автоматически (вызовом file -z).  При этом tar умеет
> > самостоятельно определять сжатие gzip или bzip2 и вызывать
> > соответствующий распаковщик, а для cpio на вход нужно подавать уже
> > распакованные данные, поэтому для сжатых cpio введены отдельные типы,
> > а для tar используется один тип независимо от сжатия.
> >
> Спасибо. С типом понятно. Это было бы хорошо в ман добавить... Пусть
> не всё. Но хоть про необязательность указания типа для неперечисленных
> случаев.
> А что такое <subdirectory>?
Это каталог, в который будут распакованы исходники.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/22 Alexey Rusakov <ktirf@>:
> В Вск, 22/03/2009 в 21:19 +0200, Andriy Dobrovol`s`kii пишет:
>> А что такое <subdirectory>?
> Это каталог, в который будут распакованы исходники.
>
gear-update -v file-2.14.tar.bz2 file-2.13/
fatal: Not a git repository

В указаном каталоге был создан начальный гит из исходников версии
2.13. Так что ж там указывать?

SYNOPSIS
       gear-update [Options] <source> <subdirectory>

Вроде всё как в мане?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Anton Farygin]

Andriy Dobrovol`s`kii пишет:
> 2009/3/22 Alexey Rusakov <ktirf@>:
>> В Вск, 22/03/2009 в 21:19 +0200, Andriy Dobrovol`s`kii пишет:
>>> А что такое <subdirectory>?
>> Это каталог, в который будут распакованы исходники.
>>
> gear-update -v file-2.14.tar.bz2 file-2.13/
> fatal: Not a git repository
> 
> В указаном каталоге был создан начальный гит из исходников версии
> 2.13. Так что ж там указывать?
> 
> SYNOPSIS
>        gear-update [Options] <source> <subdirectory>
> 
> Вроде всё как в мане?

mkdir test
cd test
git init-db
gear-update -c ~/ImageMagick-6.5.4-1.tar.bz2 ImageMagick/

Вот так правильно.

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/22 Anton Farygin <rider@>:
>
> mkdir test
> cd test
> git init-db
> gear-update -c ~/ImageMagick-6.5.4-1.tar.bz2 ImageMagick/
>
> Вот так правильно.
>
ОК. Очередная попытка...
создал в каталоге с базой гита подкаталог. и пытаюсь натащить на ветку
master новый тарбол.
gear-update -v ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
gear-update: gwyddion-2.14: Untracked or modified files found.
И снова "не лезет каменный цветок"... В этом каталоге лежат ещё спеки,
которые не учтены в этой ветке ну и сам подкаталог куда я собираюсь
уложить свежие исходники не комитился. Что не нравится утилите?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/25 Andriy Dobrovol`s`kii <adobrovolskii@>:
> 2009/3/22 Anton Farygin <rider@>:
>>
>> mkdir test
>> cd test
>> git init-db
>> gear-update -c ~/ImageMagick-6.5.4-1.tar.bz2 ImageMagick/
>>
>> Вот так правильно.
>>
> ОК. Очередная попытка...
> создал в каталоге с базой гита подкаталог. и пытаюсь натащить на ветку
> master новый тарбол.
> gear-update -v ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
> gear-update: gwyddion-2.14: Untracked or modified files found.
> И снова "не лезет каменный цветок"... В этом каталоге лежат ещё спеки,
> которые не учтены в этой ветке ну и сам подкаталог куда я собираюсь
> уложить свежие исходники не комитился. Что не нравится утилите?
В догонку:
git branch
  current
* master
git status
# On branch master
nothing to commit (working directory clean)



-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Anton Farygin]

Andriy Dobrovol`s`kii пишет:
> 2009/3/25 Andriy Dobrovol`s`kii <adobrovolskii@>:
>> 2009/3/22 Anton Farygin <rider@>:
>>> mkdir test
>>> cd test
>>> git init-db
>>> gear-update -c ~/ImageMagick-6.5.4-1.tar.bz2 ImageMagick/
>>>
>>> Вот так правильно.
>>>
>> ОК. Очередная попытка...
>> создал в каталоге с базой гита подкаталог. и пытаюсь натащить на ветку
>> master новый тарбол.
>> gear-update -v ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
>> gear-update: gwyddion-2.14: Untracked or modified files found.
>> И снова "не лезет каменный цветок"... В этом каталоге лежат ещё спеки,
>> которые не учтены в этой ветке ну и сам подкаталог куда я собираюсь
>> уложить свежие исходники не комитился. Что не нравится утилите?
> В догонку:
> git branch
>   current
> * master
> git status
> # On branch master
> nothing to commit (working directory clean)

Коммитить нужно было.

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/25 Anton Farygin <rider@altlinux.com>:
> Andriy Dobrovol`s`kii пишет:
>>
>> 2009/3/25 Andriy Dobrovol`s`kii <adobrovolskii@>:
>>>
>>> 2009/3/22 Anton Farygin <rider@>:
>>>>
>>>> mkdir test
>>>> cd test
>>>> git init-db
>>>> gear-update -c ~/ImageMagick-6.5.4-1.tar.bz2 ImageMagick/
>>>>
>>>> Вот так правильно.
>>>>
>>> ОК. Очередная попытка...
>>> создал в каталоге с базой гита подкаталог. и пытаюсь натащить на ветку
>>> master новый тарбол.
>>> gear-update -v ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
>>> gear-update: gwyddion-2.14: Untracked or modified files found.
>>> И снова "не лезет каменный цветок"... В этом каталоге лежат ещё спеки,
>>> которые не учтены в этой ветке ну и сам подкаталог куда я собираюсь
>>> уложить свежие исходники не комитился. Что не нравится утилите?
>>
>> В догонку:
>> git branch
>>  current
>> * master
>> git status
>> # On branch master
>> nothing to commit (working directory clean)
>
> Коммитить нужно было.
>
Так а что комитить? Оно же считает, что комитить нечего...
Спеки закомичены в current. В мастере они мне не нужны. Особенно
сейчас, когда с ними не собирается и сперва их нужно довести до ума...
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/25 Andriy Dobrovol`s`kii <adobrovolskii@:
>>>> ОК. Очередная попытка...
>>>> создал в каталоге с базой гита подкаталог. и пытаюсь натащить на ветку
>>>> master новый тарбол.
>>>> gear-update -v ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
>>>> gear-update: gwyddion-2.14: Untracked or modified files found.
>>>> И снова "не лезет каменный цветок"... В этом каталоге лежат ещё спеки,
>>>> которые не учтены в этой ветке ну и сам подкаталог куда я собираюсь
>>>> уложить свежие исходники не комитился. Что не нравится утилите?
>>>
>>> В догонку:
>>> git branch
>>>  current
>>> * master
>>> git status
>>> # On branch master
>>> nothing to commit (working directory clean)
>>
>> Коммитить нужно было.
>>
> Так а что комитить? Оно же считает, что комитить нечего...
> Спеки закомичены в current. В мастере они мне не нужны. Особенно
> сейчас, когда с ними не собирается и сперва их нужно довести до ума...
Про спеки я сглупил. Ничего неучтенного в каталоге нет. Я сперва
создал гит с исходниками из тарбола, закомител это всё в мастер. Потом
создал новый бранч, переключился в него и добавил рабочие спеки.
Закомитил их. Тепрь выкачал ноый тарбол. Переключился назад в мастер и
пытаюсь втянуть в него новые исходники... И никак...



-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

Привет,
Продолжим попытки...
Т.к. гуру заняты и в нашей "возне" им участвовать некогда, поез в код
gear-update... Я увы не профи в баш-программировании и понял, мягко
говоря, не всё..
Но, у меня сложилось впечатление, что оно предназначено для
инициализации, в смысле первичной закачки, гита из тарбола, а не для
последующих обновлений уже существующего гита новыми тарболами...
Потому сделал по простому. В созданый подкаталог распаковал тарбол, и
закомитил полученное поддерево...
 tar xvf ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
git add gwyddion-2.14/
git commit -a
...
вычистил файлы с исходниками прежней версии
git commit -a
...
git tag v2.14
git tag -l
v2.13
v2.14
Теперь:
git checkout v2.13
Note: moving to "v2.13" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at c5aacd3...  Initial commit
и
$ ls
ABOUT-NLS     configure         libdraw       make.msc    README
aclocal.m4    configure.ac      libgwyddion   missing     ruby
app           COPYING           libgwydgets   modules     rules.msc
AUTHORS       data              libgwymodule  NEWS        THANKS
autogen.sh    depcomp           libprocess    perl        thumbnailer
ChangeLog     devel-docs        ltmain.sh     pixmaps     TODO
config.guess  gwyddion.spec     m4            plugins     utils
config.h.in   INSTALL           Makefile.am   po
config.rpath  INSTALL.gwyddion  Makefile.in   py-compile
config.sub    install-sh        makefile.msc  python
далее:
git checkout v2.14
Previous HEAD position was c5aacd3...  Initial commit
HEAD is now at 40a2ff2... clean v. 2.13 sources
и
$ ls
gwyddion-2.14
Вроде тут всё как задумывалось...
Теперь как средствами самого гита скрестить current и текущий HEAD
мастера так чтоб в нём были рабочие спеки и только новые исходники? По
идее git-merge? Или как-то иначе?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Андрей Черепанов]

26 марта 2009, Andriy Dobrovol`s`kii написал(а):
> Привет,
> Продолжим попытки...
> Т.к. гуру заняты и в нашей "возне" им участвовать некогда, поез в код
> gear-update... Я увы не профи в баш-программировании и понял, мягко
> говоря, не всё..
> Но, у меня сложилось впечатление, что оно предназначено для
> инициализации, в смысле первичной закачки, гита из тарбола, а не для
> последующих обновлений уже существующего гита новыми тарболами...
> Потому сделал по простому. В созданый подкаталог распаковал тарбол, и
> закомитил полученное поддерево...
>  tar xvf ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
> git add gwyddion-2.14/
> git commit -a
gear-update делает это гораздо правильнее и работает не только на закачку, но 
и на обновление (что следует из названия). Я это проверял у себя в kmymoney2.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/26 Андрей Черепанов <cas@>:
> 26 марта 2009, Andriy Dobrovol`s`kii написал(а):
>> Привет,
>> Продолжим попытки...
>> Т.к. гуру заняты и в нашей "возне" им участвовать некогда, поез в код
>> gear-update... Я увы не профи в баш-программировании и понял, мягко
>> говоря, не всё..
>> Но, у меня сложилось впечатление, что оно предназначено для
>> инициализации, в смысле первичной закачки, гита из тарбола, а не для
>> последующих обновлений уже существующего гита новыми тарболами...
>> Потому сделал по простому. В созданый подкаталог распаковал тарбол, и
>> закомитил полученное поддерево...
>>  tar xvf ../gwyddion-2.14.tar.bz2 gwyddion-2.14/
>> git add gwyddion-2.14/
>> git commit -a
> gear-update делает это гораздо правильнее и работает не только на закачку, но
> и на обновление (что следует из названия). Я это проверял у себя в kmymoney2.
>
Тогда объясните, что ему мешало выполнить свою работу в моём случае и
что ещё нужно сделать чтоб было так же правильно как при применении
gear-update?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/26 Андрей Черепанов <cas@>:
> gear-update делает это гораздо правильнее и работает не только на закачку, но
> и на обновление (что следует из названия). Я это проверял у себя в kmymoney2.
Возник очередной вопрос. А кто создает файл .gear/rules и где он
должен лежать? Как-то в документации об этом невнятно...
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Alexey Novikov]

On Thu, Mar 26, 2009 at 09:51:42PM +0200, Andriy Dobrovol`s`kii wrote:
> 2009/3/26 Андрей Черепанов <cas@>:
> > gear-update делает это гораздо правильнее и работает не только на закачку, но
> > и на обновление (что следует из названия). Я это проверял у себя в kmymoney2.
> Возник очередной вопрос. А кто создает файл .gear/rules и где он
> должен лежать? Как-то в документации об этом невнятно...
Создаете - руками, лежать в том же бранче, где и спек(и).

-- 
WBR, Alexey Novikov
XMPP: alex-novikov@jabber.ru, shader@ya.ru

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/27 Alexey Novikov <shader@>:
> Создаете - руками, лежать в том же бранче, где и спек(и).
И что лучше создавать? Каталог .gear/ с файлом rules или файл
.gear-rules? На что кроме генерации пакета влияет этот файл? Лежать
это должно на том же уровне что и .git/ ?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Slava Semushin]

27 марта 2009 г. 17:05 пользователь Andriy Dobrovol`s`kii
<adobrovolskii@gmail.com> написал:
> 2009/3/27 Alexey Novikov <shader@>:
>> Создаете - руками, лежать в том же бранче, где и спек(и).
> И что лучше создавать? Каталог .gear/ с файлом rules или файл
> .gear-rules?

Насколько понимаю, .gear/rules предпочительнее, хотя сейчас они и равноправны.

> На что кроме генерации пакета влияет этот файл? Лежать
> это должно на том же уровне что и .git/ ?

Да.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [Comm] git and packaging

[Alexey Novikov]

On Fri, Mar 27, 2009 at 05:07:45PM +0600, Slava Semushin wrote:
> 27 марта 2009 г. 17:05 пользователь Andriy Dobrovol`s`kii
> <adobrovolskii@gmail.com> написал:
> > 2009/3/27 Alexey Novikov <shader@>:
> >> Создаете - руками, лежать в том же бранче, где и спек(и).
> > И что лучше создавать? Каталог .gear/ с файлом rules или файл
> > .gear-rules?
> 
> Насколько понимаю, .gear/rules предпочительнее, хотя сейчас они и равноправны.
ЕМНИП .gear-rules - obsoleted, оставлено для совместимости
 
> > На что кроме генерации пакета влияет этот файл? Лежать
> > это должно на том же уровне что и .git/ ?
> 
> Да.
Т.е. что-то типа (здесь upstream и fixes отдельными бранчами)

$ ls -al
итого 20
drwxr-xr-x  4 novikov novikov 4096 Мар 17 11:19 .
drwxr-xr-x 19 novikov novikov 4096 Мар 17 16:15 ..
drwxr-xr-x  3 novikov novikov 4096 Мар 17 11:20 .gear
drwxr-xr-x  8 novikov novikov 4096 Мар 17 11:26 .git
-rw-r--r--  1 novikov novikov 1744 Мар 17 11:20 foo.spec

-- 
WBR, Alexey Novikov
XMPP: alex-novikov@jabber.ru, shader@ya.ru

Re: [Comm] git and packaging

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

В Вск, 22/03/2009 в 22:26 +0200, Andriy Dobrovol`s`kii пишет:
> 2009/3/22 Alexey Rusakov <ktirf@>:
> > В Вск, 22/03/2009 в 21:19 +0200, Andriy Dobrovol`s`kii пишет:
> >> А что такое <subdirectory>?
> > Это каталог, в который будут распакованы исходники.
> >
> gear-update -v file-2.14.tar.bz2 file-2.13/
> fatal: Not a git repository
> 
> В указаном каталоге был создан начальный гит из исходников версии
> 2.13. Так что ж там указывать?
В указанном - это в file-2.13? Вы, вероятно, неправильно поняли.
gear-update нужно выполнять, находясь в каталоге с подкаталогом .git, и
указать в качестве параметра подкаталог, в который будут положены
исходники (это может быть и ./, но обычно кладут всё же в отдельный
подкаталог рядом со спеком).

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

Привет,
В рассуждениях о гит как аргумент звучало "экономия места на винте".
Тарбол программки имеет вес 2,5 мега. каталог с гитом 35... Правда там
лежат распакованные исходники. Их можно удалить после закомичивания?
Но ведь с ними работать надо... Или я упустил что-то важное?
-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Damir]

22 марта 2009 г. 20:43 пользователь Andriy Dobrovol`s`kii
<adobrovolskii@gmail.com> написал:
> Привет,
> В рассуждениях о гит как аргумент звучало "экономия места на винте".
> Тарбол программки имеет вес 2,5 мега. каталог с гитом 35... Правда там
> лежат распакованные исходники. Их можно удалить после закомичивания?
> Но ведь с ними работать надо... Или я упустил что-то важное?

git gc --aggressive

Re: [Comm] git and packaging

[Aleksander Gorohovski]

On Mon, 16 Mar 2009 17:16:50 +0200, Andriy Dobrovol`s`kii wrote:

> Hi,
> После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
> Почитал документацию.  <skipped>

Sorry,  подскажи(те)
а где более менее полную + внятную документацию можно почитать о гит?

Желательно на великом и могучем.

Re: [Comm] git and packaging

[Андрей Черепанов]

16 марта 2009, Aleksander Gorohovski написал(а):
> On Mon, 16 Mar 2009 17:16:50 +0200, Andriy Dobrovol`s`kii wrote:
> > Hi,
> > После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
> > Почитал документацию.  <skipped>
>
> Sorry,  подскажи(те)
> а где более менее полную + внятную документацию можно почитать о гит?
>
> Желательно на великом и могучем.
altlinux.org/Git. Там есть всё на великом и могучем.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Aleksander Gorohovski]

On Mon, 16 Mar 2009 18:07:43 +0200, Андрей Черепанов wrote:

> 16 марта 2009, Aleksander Gorohovski написал(а):
>> On Mon, 16 Mar 2009 17:16:50 +0200, Andriy Dobrovol`s`kii wrote:
>> > Hi,
>> > После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
>> > Почитал документацию.  <skipped>
>>
>> Sorry,  подскажи(те)
>> а где более менее полную + внятную документацию можно почитать о гит?
>>
>> Желательно на великом и могучем.
> altlinux.org/Git. Там есть всё на великом и могучем.

Андрей,
Премного благодарен.
:)

Re: [Comm] git and packaging

[Andrew Borodin]

On Mon, Mar 16, 2009 at 05:56:16PM +0200, Aleksander Gorohovski wrote:
> а где более менее полную + внятную документацию можно почитать 
> о гит?
> Желательно на великом и могучем.

http://los-t.livejournal.com/tag/git+guts

-- 

С уважением
А. Бородин.

Re: [Comm] git and packaging

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Tue, Mar 17, 2009 at 09:44:30AM +0300, Andrew Borodin wrote:
> > а где более менее полную + внятную документацию можно почитать 
> > о гит?
> > Желательно на великом и могучем.
> http://los-t.livejournal.com/tag/git+guts
Это не документация, это guts.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Полон багов в Сизиф ушел Гном-2.6.0.
		-- aris in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] git and packaging

[Andrew Borodin]

On Tue, Mar 17, 2009 at 12:04:08PM +0500, Andrey Rahmatullin wrote:
> > http://los-t.livejournal.com/tag/git+guts
> Это не документация, это guts.

"Документация" -- понятие растяжимое...

-- 

С уважением
А. Бородин.

Re: [Comm] git and packaging

[Андрей Черепанов]

17 марта 2009, Andrew Borodin написал(а):
> On Mon, Mar 16, 2009 at 05:56:16PM +0200, Aleksander Gorohovski wrote:
> > а где более менее полную + внятную документацию можно почитать
> > о гит?
> > Желательно на великом и могучем.
>
> http://los-t.livejournal.com/tag/git+guts
На altlinux.org/Git есть и эта ссылка. ;)

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] git and packaging

[Andrew Borodin]

On Tue, Mar 17, 2009 at 10:57:33AM +0300, Андрей Черепанов wrote:
> > http://los-t.livejournal.com/tag/git+guts
> На altlinux.org/Git есть и эта ссылка. ;)

Поленился сходить.

-- 

С уважением
А. Бородин.

Re: [Comm] git and packaging

[Michael Shigorin]

On Mon, Mar 16, 2009 at 05:16:50PM +0200, Andriy Dobrovol`s`kii wrote:
> После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
> Почитал документацию. Вижу, что гит это просто ещё одна CVS.

 ет.

http://www.altlinux.org/Git#.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8
(особенно "вводные статьи")

Если нечего делать -- можешь глянуть ещё и
http://www.opennet.ru/openforum/vsluhforumID3/42153.html#32

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/24 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, Mar 16, 2009 at 05:16:50PM +0200, Andriy Dobrovol`s`kii wrote:
>> После гарячей дискуссии по поводу бэкпотров решился "поковырять" гит.
>> Почитал документацию. Вижу, что гит это просто ещё одна CVS.
>
>  ет.
>
> http://www.altlinux.org/Git#.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8
> (особенно "вводные статьи")
>
Читал и продолжаю перечитывать. Потому и взялся отделять рекламу от
реальности...
> Если нечего делать -- можешь глянуть ещё и
> http://www.opennet.ru/openforum/vsluhforumID3/42153.html#32
Посмотрим.

-- 
Regards,
Andrii Dobrovol`s`kyj

Re: [Comm] git and packaging

[Andriy Dobrovol`s`kii]

2009/3/24 Andriy Dobrovol`s`kii <adobrovolskii@>:
> 2009/3/24 Michael Shigorin <mike@>:
>> Если нечего делать -- можешь глянуть ещё и
>> http://www.opennet.ru/openforum/vsluhforumID3/42153.html#32
> Посмотрим.
>
Глянул. Занятно конечно. Но я и раньше не отрицал полезность гита при
реальной разработке.
Сейчас у меня совсем другие вопросы...
Куда конкретнее...
-- 
Regards,
Andrii Dobrovol`s`kyj