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коммитов.  Грустно смотреть, на
> что порой расходуют себя умные люди.

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

  Предложение приветствуются.

-- 

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