Параметр --verify для gear-update-tag не помешает.
Только ведь можно и --verify забыть запустить.
Поэтому мне кажется логичным научить "gear-update-tag --verify" работать с commitish и добавить соответствующий вызов в gear-create-tag.

Я приделаю commitish к gear-update-tag.

Не уверен насчёт gear-create-tag.  Логичней было бы gear в режиме --rpm/--hasher/pkg.tar.

Сделал, но если в .gear/tags используются имена бранчей а не тегов, толку от этого будет мало.

Reassing и жду замечаний или мержа.

(In reply to comment #3)
> Сделал, но если в .gear/tags используются имена бранчей а не тегов, толку от этого
> будет мало.
> 

check_tag_name() не позволит использовать не тэги. Собственно в этом и проблема #15610.

(In reply to comment #5)
> check_tag_name() не позволит использовать не тэги.

И давно?  См. напр. mutt1.5.

(In reply to comment #6)
> И давно?  См. напр. mutt1.5.

Интересно:

check_tag_name() 
{ 
  local name="$1" && shift 

  [ -n "$name" ] || 
    rules_error 'Empty tag name is not allowed' 
  [ -n "${name##/*}" ] || 
    rules_error "Invalid tag name \"$name\": initial '/' is not allowed" 
  [ -n "${name%%*/}" ] || 
    rules_error "Invalid tag name \"$name\": trailing '/' is not allowed" 
  [ -n "${name##*[][*?^~:@[:space:]]*}" ] || 
    rules_error "Invalid tag name \"$name\": invalid characters found" 
  git check-ref-format "tags/$name" || 
    rules_error "Invalid tag name \"$name\"" 
}

это функция проверки имени тэга. Начальные проверки имени ясны. Интересен git check-ref-format.

[legion gear]$ git check-ref-format 'tags/foobar'; echo $?
0
[legion gear]$ git rev-parse 'tags/1.0.1-alt1'; echo $?
0a47c66dedd606aeb028f6c8db65ab447c6e211a
0
[legion gear]$ git check-ref-format 'tags/foobar'; echo $?
0
[legion gear]$ git rev-parse 'tags/foobar'; echo $?
tags/foobar
fatal: ambiguous argument 'tags/foobar': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
128

Кажется поэтому ты и можешь использовать имена бранчей.

Либо я в чём-то сильно ошибаюсь.

Хотя нужно внимательнее прочитать resolve_commit_name().

Хм.

$ git check-ref-format tags/master && echo OK || echo ERR
OK
$ git check-ref-format master && echo OK || echo ERR 
ERR
$ git check-ref-format refs/heads/master && echo OK || echo ERR 
OK
$ git check-ref-format refs/tags/master && echo OK || echo ERR 
OK

Хм. Хм.

$ git show-ref master
a601b50cc564a73ddcd777c76cfe45a44317cc58 refs/heads/master
a601b50cc564a73ddcd777c76cfe45a44317cc58 refs/remotes/origin/master
$ git show-ref tags/master
[1]    18797 exit 1     git show-ref tags/master
$ git show-ref refs/heads/master
a601b50cc564a73ddcd777c76cfe45a44317cc58 refs/heads/master
$ git show-ref refs/tags/master 
[1]    18847 exit 1     git show-ref refs/tags/master

(In reply to comment #9)
> Хм.
> 
> $ git check-ref-format tags/master && echo OK || echo ERR

Вот-вот ... такое ощущение, что раньше check-ref-format проверял не только корректность имени, но и существование этого объекта.

ну и разумеется:

gear-update-tag "name" -> check_tag_name_from_command_line -> check_tag_name

поэтому бранчи вместо тэгов можно создавать.

Мне бы хотелось чтобы это так и осталось...  Иначе придётся лепить tip'ы на каждый бранч, что ещё неудобнее.

Тут получается сложная ситуация ... бранч нарушает концепцию однозначной
определённости коммита. Но такая конструкция уже используется и ты этому иллюстрация.

Вообщем, нужно думать как это решать.

P.S. Мне кажется, что всё-таки нужно запрещать использование бранчей. Это ломает всю идею этой утилиты.

Как раз наоборот.  Эта утилита фиксирует имена тегов/бранчей на момент сборки.  Мне удобно использовать бранчи, зачем усложнять людям жизнь?  Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше шансов накосячить так, что никто этого не заметит (уже чинил такое).

(In reply to comment #14)
> Как раз наоборот.  Эта утилита фиксирует имена тегов/бранчей на момент
> сборки.  Мне удобно использовать бранчи, зачем усложнять людям жизнь? 
> Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше
> шансов накосячить так, что никто этого не заметит (уже чинил такое).
> 

Я тоже иногда использую бранчи, см. coreutils.git

Угу. gear-update-tag фиксирует sha1 объекта при добавлении в .gear/tags.

Тогда Лёшь, как быть с 16075#c3 ?

P.S. Слова "мне так удобно" или "я так привык" за агрумент не считаю.

Для меня загадка почему vsu так ограничил "diff: ...". К сожалению он на письма тоже не отвечает.

(In reply to comment #16)
> Тогда Лёшь, как быть с 16075#c3 ?
Симриться.  Тега, который был зафиксирован при помощи gear-update-tag может не быть в репозитарии или он уже может указывать на другой об'ект.  Именно для этого и делался gear-update-tag.

gear-update-tag работает с working copy, --verify только проверяет что запуск gear-update-tag --all в данный момент ничего не сделает.

> P.S. Слова "мне так удобно" или "я так привык" за агрумент не считаю.
Как насчёт слов "неувеличение энтропии"?  Зачем делать два и более действий там, где достаточно одного?

(In reply to comment #18)
> (In reply to comment #16)
> > Тогда Лёшь, как быть с 16075#c3 ?
> Симриться.  Тега, который был зафиксирован при помощи gear-update-tag может не быть
> в репозитарии или он уже может указывать на другой об'ект.  Именно для этого
> и делался gear-update-tag.

Как я понимаю сейчас gear-update-tag поступает с бранчами также как тэгами. Он и те и другие имена заносит в .gear/tags и вычитывает из rules т.е. по коду они не отличимы.

Почему же ты считаешь что при использовании бранчей от --verify толку будет мало?
 
> gear-update-tag работает с working copy, --verify только проверяет что запуск gear-update-tag --all в
> данный момент ничего не сделает.

Нам нужно исправлять gear-update-tag для корректной работы с бранчами. Сейчас для бранчей он не полнофункционален. Вот пример:

if [ -n "$tag_name" ] && [ -z "$delete" ]; then
  if [ -z "$tag_value" ]; then
    tag_value="$(get_object_sha1 refs/tags/"$tag_name")" ||
      fatal "Invalid tag \"$tag_name\""
...

Нужно думать как убрать неоднозначность $tag_name.

Затеял исправление этой утилиты под наши реали:

http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/gear-update-tag

(In reply to comment #19)
> Почему же ты считаешь что при использовании бранчей от --verify толку будет
> мало?

Я не так выразился.  Мало толку будет от использования --verify --tree-ish в том
случае когда об'екты (бранчи или теги) из .gear/tags изменились.  В бранч
накоммитили или tip-тег подвинули - без разницы.

Я не знаю как 100% определить случай, когда человек забыл подвинуть tip-тег,
поэтому использую имена бранчей, кроме обязательного требования
использовать только верионные tip-теги, но это уже помойму перебор.

(In reply to comment #21)
> Я не так выразился.  Мало толку будет от использования --verify --tree-ish в том
> случае когда об'екты (бранчи или теги) из .gear/tags изменились.  В бранч
> накоммитили или tip-тег подвинули - без разницы.

А почему нельзя проверить sha1 из .gear/tags c sha1 на который указывает тег/бранч ?

(In reply to comment #22)
> А почему нельзя проверить sha1 из .gear/tags c sha1 на который указывает тег/бранч ?
Не понял вопроса.

> Я не знаю как 100% определить случай, когда человек забыл подвинуть tip-тег,
> поэтому использую имена бранчей, кроме обязательного требования
> использовать только верионные tip-теги, но это уже помойму перебор.

Так. Чтобы не толочь воду в ступе, можешь более детально поясинть, какую ситуацию нужно определить ? 

.gear/rules:
tar: master:.

Если забыть обновить .gear/tags при сборке нового пакета соберётся предыдущая версия с новым спеком.  gear не ругнётся, поскольку HEAD растёт из "старого master".

(In reply to comment #25)
> .gear/rules:
> tar: master:.
> 
> Если забыть обновить .gear/tags при сборке нового пакета соберётся предыдущая
> версия с новым спеком.  gear не ругнётся, поскольку HEAD растёт из "старого master".
> 

Т.е. если пользователь передвинул тег перечисленный в .gear/tags и не сказал gear-update-tag ?

Именно.

(In reply to comment #26)
> Т.е. если пользователь передвинул тег перечисленный в .gear/tags и не сказал
> gear-update-tag ?

Получается что в .gear/tags сохранено старое (предыдущее) состояние. Оно выглядет например так:

$ cat .gear/tags/list 
d138e5e3a47f7fced4435116e3cd9210b3e0d1fc aterm-1.0.1

Нам нужно посмотреть на какой объект указывает aterm-1.0.1 сейчас и сравнить его с d138e5e3a47f7fced4435116e3cd9210b3e0d1fc (старым значением). Если они не совпадут, то совершенно понятно, что тег aterm-1.0.1 передвинули, но не обновлили .gear/tags/list. Разве нет ?

Ты издеваешься, да?  Именно это и делает gear-update-tag --verify.

(In reply to comment #29)
> Ты издеваешься, да?  Именно это и делает gear-update-tag --verify.

Именно. Я к тому что я не очень понимаю проблемы 16075#c25. Разве что отсутствия такой же проверки в gear.

Ты всё-таки надо мной издеваешься.  Зачем ты это делаешь?

(In reply to comment #31)
> Ты всё-таки надо мной издеваешься.  Зачем ты это делаешь?

Я вижу мы с тобой никак не можем найти общий язык. Я этот флейм прекращаю. Твои изменения я смерджил в gear-next. Дима их может взять либо у меня, либо у тебя.

Сс: -legion@

(In reply to comment #15)
> (In reply to comment #14)
> > Как раз наоборот.  Эта утилита фиксирует имена тегов/бранчей на момент
> > сборки.  Мне удобно использовать бранчи, зачем усложнять людям жизнь? 
> > Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше
> > шансов накосячить так, что никто этого не заметит (уже чинил такое).
> 
> Я тоже иногда использую бранчи, см. coreutils.git

Погорячился. Не использую я бранчи в .gear/rules

(In reply to comment #33)
> Погорячился. Не использую я бранчи в .gear/rules 

А это не важно. Если есть хоть один человек, то нет гарантии что он такой один. Я даже не знаю как долго у нас разрешено такое поведение.

По поводу разрешения использования бранчей вместо тегов, как сделано в http://git.altlinux.org/people/legion/packages/?p=gear.git;a=commitdiff;h=376cbf3c9fe77c78eb4f61872db16cd0b85be7c3 - уже не помню, почему я написал именно так, но в принципе в этом месте можно использовать даже git rev-parse --verify, поскольку этот код в любом случае выполняется у мантейнера. В случае неоднозначности всегда можно вызвать gear-update-tag с двумя параметрами (точно так же можно засунуть туда бранч вместо тега уже сейчас).

Вызов git check-ref-format был предназначен только для отлова недопустимых символов, причём "tags/" там используется только из-за того, что git check-ref-format требует наличия хотя бы одного символа "/" в параметре.  На сам ом деле сейчас это работает не совсем правильно, поскольку текущий код передаёт в git check-ref-format конструкции вида @name@, рассчитывая на то, что они пройдут проверку, однако сейчас в git символ '@' имеет специальное значение, просто git check-ref-format почему-то его не отлавливает.

Исправлено. Закрываю.

Ключ добавлен.