On Thu, Jun 22, 2006 at 06:56:47PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [060622 15:30]:
> > > Точно также может измениться и сам ID.
> > Который ID?  Тот, что передаётся в качестве параметра утилите gear?
> Он самый.
> 
> > Считается, что запускающий gear контролирует передаваемые параметры,
> > в отличие от содержимого репозитория.
> Каким образом можно контролировать передаваемые параметры,
> которые в свою очередь зависят от содержимого репозитария?

Их можно проверять, полагаясь на целостность предварительно проверенного
репозитория.  Если собирать по тегу, то можно проверить этот тэг с тем,
чтобы точно знать, что собираешь.

> Самый
> главный вопрос - как проверить что "запускающий gear" это
> контролирует?

Это личное дело запускающего, для меня важно предоставить такую
возможность.

> > > Почему он может так
> > > "вдруг" измениться (кроме случая когда указан како-ньдь HEAD)?
> > Просто потому что ничего не мешает ему измениться без нарушения
> > целостности git-репозитория.
> Я всё-таки не понимаю, чем ситуация с одним tree-ish в корне
> отличается от ситуации с двумя tree-ish, где второй зависит от
> совержимого первого?

Это просто:  при нынешней схеме переданный утилите gear tree-ish
(идентификатор, однозначно идентифицирующий объект типа tree) однозначно
определяет результат вне зависимости от того, как настроен репозиторий.
Если разрешить в правилах для gear использовать ссылки на объекты, не
связанные с переданным утилите gear идентификатором (если говорить строго,
я имею в виду такие идентификаторы, изменение которых не нарушает
валидность tree-ish), то эта однозначность не будет гарантирована.

По моему, это очень плохо, если результат сборки архива по одному и тому же
tree-ish, однозначно идентифицирующему объект, может отличаться от запуска
к запуску.  Речь идёт даже не столько о диверсии, сколько об элементарной
операции замены используемого в правилах тэга (git-tag -f).

Не знаю, может и есть способ как-то привязать эти тэги к tree-ish.


-- 
ldv