[devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Денис Смирнов]

On Sun, Jan 10, 2010 at 04:32:48PM +0300, Afanasov Dmitry wrote:

AD> что я считаю бредом. пока у gear не будет зависимостей, пока apt-get
AD> source не поставит нужную репу, пока не появится новый gear package
AD> manager, gear будет не более чем хранилищем, а результатом будет всё
AD> тот же srpm.
AD> srpm не промежуточный формат, srpm - результат. хехе, hasher и тот
AD> зависимости вычисляет через rpmquery -qR <srpm>.

Вот потому он и является промежуточным форматом. Оригинал -- это spec, в
gear repo. Результат -- это rpm. А srpm это так, дополнительный, но
_действительно важный_ результат. Важный в том числе для apt-get source,
например :)

AD> важно - готовый патч проще взять и приложить, чем взять репу и вычислять,
AD> откуда что растет.
AD> /me представить страшно, если на packages.<distr>.org перестанут как у нас
AD> выкладывать патчи.

Я попробую пояснить, только попрошу не обижаться.

Мне, как мантейнеру, не платят ни копейки. И мои _обязательства_ поэтому
ограничиваются всего лишь одним пунктом -- не мешать жить другим. Если
подробнее -- соблюдать полиси и не кидать заведомые бомбы в Сизиф.

Так вот, _заставить_ меня выполнять упаковку пакетом невозможно, никак.
Просто если у меня есть возможность -- я отправлю пакет в Сизиф (чтобы
коллегам жизнь облегчить, да и чтобы самому потом не потерять).

На подобные вещи у меня есть некоторый ограниченный ресурс времени, ибо
это _свободное_ время (а еще и работать надо), и _не все_ свободное время
(ибо отдыхать от компа надо).

Поэтому, очевидно, я буду выбирать самый времяэффективный метод для этой
работы.

Работа по формированию отдельных патчей занимат в разы больше времени, чем
сборка с двумя бранчами (upstream/master), которой я сейчас пользуюсь.

С радостью отдам большинство своих пакетов тем, кто захочет их упаковать
лучше.

Если меня попытаться обязать паковать более медленным образом -- я просто
перевешу большинство своих пакетов на nobody, и буду паковать их у себя
локально ровно так, как мне необходимо для работы. В результате не будет
"более красиво упакованных пакетов", их будет тривиально меньше.

Думаю что аналогичный подход у большинства мантейнеров. 

Обвинять в этом git как технологию также неправильно. git дал возможность
работать _более быстро_, но одним патчем. При этом тем, кто хочет
разобраться в этом пакете -- придется смотреть в git repo, а не srpm.



Мне совершенно непонятно, почему я лично должен забесплатно тратить больше
времени на сборку, чтобы облегчить жизн тем, кто не соизволил разобраться
с git.

Не можете разобраться в моей сборке? Соберите лучше и понятнее для себя. Я
даже пакет отдам, если сборка будет действительно лучше.

Я с интересом будут обсуждать схемы организации работы, которые позволят
удобнее работать с git repo, в том числе чужими. Это нужное дело.
Обсуждать то, как облегчить жизнь тем кто хочет продолжать использовать
srpm ценой затрат _моего личного времени_ -- я готов только если эти
любители srpm за свое нежелание учиться и желание тратить мое время начнут
платить мне деньги.

AD> кажись именно её я и озвучил :)

Возможно я не понял :)

AD> да-да-да, буквально рядом отписался о том же.
AD> я даже более вопрос ставлю: структура git такова, что после каждого clone
AD> мы получаем новый репозитарий со своей историей. 

А вот это явный бред. commit-id у репозитория и сделанных с него хоть
тысячей клонов будут абсолютно идентичными.

AD> видно это тогда, когда
AD> репозитарии на работе, дома и на git.alt рассинхронизируются - в этом
AD> случае мы получаем merge с раздвоением истории.

Это происходит, скорее всего вот почему:

есть некий HEAD в вашем репо на git.alt
вы сделали коммит A дома, и не запушили его
потом сделали коммит B на работе (поверх HEAD) и запушили его
потом пришли домой, и, опаньки! нужен merge.

решаются такие вещи тривиально:
1. перед началом работы не забывать делать pull
2. после окончания работы делать push
3. если работа длительная, параллельная, то это действительно по сути
отдельный бранч. Но часто достаточно воспользоваться всего лишь git
rebase.

AD> проще говоря: каждая репа - это новый бранч.

Нет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20100110/12a546fe/attachment.bin>