[devel] [SCM] packages/qemu: heads/master
Aleksey Avdeev
solo на solin.spb.ru
Пн Янв 11 17:30:17 UTC 2010
10.01.2010 04:08, Dmitry V. Levin пишет:
> On Thu, Dec 31, 2009 at 01:39:34AM +0300, Aleksey Avdeev wrote:
>> 31.12.2009 01:05, Dmitry V. Levin пишет:
>>> On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
>>>> 31.12.2009 00:06, Dmitry V. Levin пишет:
>>>>> Aleksey, PLEASE STOP poisoning repositories!
>>>>
>>>> ?
>>>
>>> Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
>>> засоряющие их коммиты! Несколько десятков коммитов для того, чтобы
>>> внести тривиальное изменение в спек!! Неужели не очевидно, что это
>>> ужасно???
>>
>> Не очевидно, т. к. данный минус перекрывается плюсами:
>>
>> 1. _Сразу_ видно откуда растут данные изменения: сохраняется история
>> каждой вмерженной фичи.
>
> В данном случае у изменения в несколько строк история в 42 коммита:
>
> $ git diff --stat 0.11.92-alt1..0.11.92-alt1-42-g44d98bd
> qemu.spec | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
Да. И 3 строчки данных изменений опираются на вмерженные изменения
репозитория specs.git (см.
<http://git.altlinux.org/people/solo/public/specs.git?p=specs.git;a=commitdiff;h=ac8bb6364cd7432255b61a64d147c1691635ea7f>):
$ git diff --stat ac8bb6364cd7432255b61a64d147c1691635ea7f{^,}
sample.spec | 22 ++--------------------
1 files changed, 2 insertions(+), 20 deletions(-)
И изменятся ли эти 3, привнесённые из specs.git, строчки далее -- я
предсказать не берусь.
>
> И чтение вывода git log 0.11.92-alt1..0.11.92-alt1-42-g44d98bd не наводит
> (меня, по крайней мере) не на какие конструктивные мысли.
Как минимум там есть упоминания о мержах с другим репозиторием (в
котором автоформировалка релизов и разрабатывалась):
commit b936e08ac4383f23fc068a96cebf94bcb3921df5
Merge: 62d4d54 69e4cf6
Author: Aleksey Avdeev <solo на altlinux.ru>
Date: Sun Dec 27 03:41:30 2009 +0300
Merge branch 'ALT/release/distr/program' of
git://git.altlinux.org/people/solo/public/specs into ALT/qemu/sample/spec
>
>> 2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
>> И как показала практика обновления автоматизатированной генерации
>> релизов (переход от кучи макросов к %branch_release) -- достаточно
>> простого мержа.
>
> Легко меняется? Там всего несколько строк изменений, однако _каждый_ merge
> приводит к конфликту, который приходится исправлять вручную.
О каких именно мержах идёт речь?
У меня есть репозитории где переход от автовычеслялки старого типа к
использованию %branch_release (приведённый выше diff) выполнялся с
помощью мержа с бранчем содержащим коммит
ac8bb6364cd7432255b61a64d147c1691635ea7f. Конфликт был простейшим (релиз
был не alt1).
>
>>> Не говоря уже про тиражирование ошибок в английских словах.
>>
>> Патчи приветствуются: я не настолько хорошо знаю инглиш, чтобы видеть
>> в нём ошибки.
>
> Историю коммитов невозможно пропатчить.
Готов её переписать, если требуется. (Или исправить без переписывания,
дабы не тиражировать ошибки далее.)
>
>> PS: Я не настаиваю именно на своём варианте:
>
> Однако вы настаиваете на своём методе, который по сути есть ни что иное
> как графо^Wгитоманство и перевод чернил^Wкоммитов. Грустно смотреть, на
> что порой расходуют себя умные люди.
Возможно. Но я пока не понял как другим образом иметь "живой"
(развивающийся, с собственной историей) пул заготовок с частями спеков и
как именно эти части в спеки внедрять (без обрыва их истории).
Предложение приветствуются.
--
С уважением. Алексей.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 554 байтов
Описание: OpenPGP digital signature
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20100111/071bfbad/attachment.bin>
Подробная информация о списке рассылки Devel