[devel] tar.gz в .gear-rules из другого git-репозитария

Aleksey Avdeev =?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Чт Апр 5 00:26:35 MSD 2007


Eugene Prokopiev пишет:
>>  То что закачал вчера:
>>
>>$ git-show-ref
>>17c715778e695ce1c4dc46f9d10a79bd6661fa66 refs/heads/dbmail_2_2
>>784c1362118790ec0a0190327743fdef7a1763cf refs/heads/dbmail_2_3_workers
>>47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/master
>>47e456d522365574e24b2455c59a79a94cc3e8e0 refs/heads/origin
>>0f6f20144ee5e5035c54a42a14b6289a324bbe89 refs/tags/dbmail/2.2.4
>>
>>  Тэг здесь только 1 -- dbmail/2.2.4
>>(0f6f20144ee5e5035c54a42a14b6289a324bbe89), созданный мной.
> 
> 
> Очень странно. Я сейчас сделал git-fetch и увидел то, что и видел 
> раньше: в heads только master, в remotes/origin - HEAD, dbmail_2_2, 
> dbmail_2_3_workers, master. У вас есть какие-нибудь предположения, 
> отчего может быть такая разница?

  Я не делал git-fetch, но делал git-clone. Плюс смотрел броузером
непосредственно по следующим адресам:

1. <http://nfg3.nfgs.net/git/dbmail.git/remotes/>

2. <http://nfg3.nfgs.net/git/dbmail.git/refs/tags/>

3. <http://nfg3.nfgs.net/git/dbmail.git/refs/heads/>


> 
> 
>>>Можно ли генерировать тарболл, основываясь на ссылке 
>>>refs/remotes/origin/dbmail_2_2?
>>
>>
>>  Подозреваю что нет: Судя по содержимому и формату ChangeLog`а это
>>ветка разработки. И факт, что найдётся некий dbmail-2.2.x
>>соответствующий коммиту 17c715778e695ce1c4dc46f9d10a79bd6661fa66.
>>Вероятность того, что это один из промежуточных (от dbmail-2.2.x к
>>dbmail-2.2.y) коммитов, на мой взгляд, выше.
> 
> 
> Да, но именно тарболл с самыми свежими изменениями на пути к 
> dbmail-2.2.5 мне и нужен. Попутный вопрос: как правильно именовать 
> пакет, собранный из такого промежуточного тарболла?

  2.2.4.x?

  ИМХО: Самый последний трабл (не отмеченный как релиз и/или RC) брать
возможно и не стоит: кто знает, что там сломано на пути к релизу... (Но
в любом случаи это вам виднее: я не в контексте.)

> 
> 
>>>И как просто извлечь исходники, 
>>>соотвествующие ей?
> 
> 
> Т.е. вопрос актуален
> 
> 
>>>Почему вы вместо этого отметили коммит 
>>>47e456d522365574e24b2455c59a79a94cc3e8e0?
>>
>>
>>  Из -за его комментария: "2.2.4 release". + по содержимому ChangeLog`а
>>он похож на результат распаковки
>><http://www.dbmail.org/download/2.2/dbmail-2.2.4.tar.gz>
>>
>>>И какой командой вы это сделали?
>>
>>
>>  git-tag
> 
> 
> Это я понял ;) Меня интересовали параметры, таг ведь вроде должен 
> создаваться на основе какого-то коммита (?), но в man git-tag я этого не 
> нашел :(

  git-tag -a -m 'dbmail 2.2.4' dbmail/2.2.4
8933d53ab39c352cc0ffdb8dfe44cae901a5c0f7

> 
> 
>>>Остальное в первом приближении понятно, попробую позже воспроизвести ...
>>
>>
>>  Общие мысли, касательно ситуации:
>>
>>1. Судя по использованию конструкций вида refs/remotes/... -- автор
>>использует git-svn: на refs/remotes/<имя бранча> данное средство
>>отображает содержимое branches SVN репозитария.
>>
>>2. Теги могут быть потеряны при неаккуратном git-push, выполненным
>>автором (я на это нарывался).
>>
>>3. Судя по тому, что репозитарии выкаченные в разное время вами и мной
>>отличаются по структуре -- проект на стадии смены инфраструктуры хранения...
> 
> 
> Речь о git-репозитарии или о svn? Просто я только что сделал git-fetch, 
> а того, о чем вы говорите, не вижу :(

  О <http://nfg3.nfgs.net/git/dbmail.git>.

  git-fetch может и не показывать: он забирает коммиты, но несохраняет
структуру репозитария. Точнее, по умолчанию, он укладывает забранные
коммиты в существующую структуру репозитария. (Прошу знатоков git меня
поправить, если не прав.)

> 
>>  Думаю, стоит списаться непосредственно с автором.
> 
> 
> Автор ни о каких подводных камнях не упоминал, когда давал ссылку на git 
> -репозитарий. Мне, собственно, нужна возможность делать пакеты на основе 
> промежуточных версий от 2.2.4 до 2.2.5 и далее (чтобы оперативно 
> устранять критичные для меня проблемы, пофикшенные апстримом). Может 
> дешевле делать это на основе svn-репозитария (чтобы избежать проблемы 
> 2)? В svn, кстати, тоже перестали делать таги после 2.0. Это значит, что 
> тарболлы для загрузки делаются просто на основе каких-либо коммитов 
> (возможно последних в бранче на момент создания тарболла)?

  Может быть. По изменению формата ChangeLog оно похоже (ChangeLog у
2.0.x -- другой по структуре). Но это стоит уточнить непосредственно у
автора.

  Если такой вариант имеет место -- то просто создавайте тэги в нужных
вам местах. Или, как вариант -- в нужных местах создавайте тег с
постоянным именем (через "git-tag -f -a -m 'dbmail 2.2.4.x for rpmbuild'
 dbmail/2.2.4-rpm XXXXX"), и неважно, что это будут разные коммиты (если
про gear-update-tag не забывать).

-- 

С уважением. Алексей.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 548 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070405/b21111a6/attachment-0001.bin>


Подробная информация о списке рассылки Devel