16075 2008-06-17 21:05:53 +0400 [FR] gear-update-tag: add "verify" mode 2008-08-24 01:41:13 +0400 1 1 4 Development Sisyphus gear unstable all Linux CLOSED FIXED http://git.altlinux.org/people/raorn/packages/?p=gear.git;a=shortlog;h=refs/heads/verify-tag patch P2 enhancement --- 1 raorn ldv glebfm ldv legion placeholder vsu vvk qa-sisyphus oldest_to_newest 72629 0 raorn 2008-06-17 21:05:53 +0400 Когда в .gear/rules используются левые бранчи, которые мержатся в master, очень легко забыть запустить gear-update-tag перед сборкой пакета. Хочется иметь опцию --verify, которая проверяла, все ли теги в .gear/tags смотрят куда положено. Ну и выходила бы с ненулевым статусом если нет. 72648 1 ldv 2008-06-18 03:29:40 +0400 Параметр --verify для gear-update-tag не помешает. Только ведь можно и --verify забыть запустить. Поэтому мне кажется логичным научить "gear-update-tag --verify" работать с commitish и добавить соответствующий вызов в gear-create-tag. 72676 2 raorn 2008-06-18 15:41:27 +0400 Я приделаю commitish к gear-update-tag. Не уверен насчёт gear-create-tag. Логичней было бы gear в режиме --rpm/--hasher/pkg.tar. 72690 3 raorn 2008-06-18 21:34:46 +0400 Сделал, но если в .gear/tags используются имена бранчей а не тегов, толку от этого будет мало. 72691 4 raorn 2008-06-18 21:36:31 +0400 Reassing и жду замечаний или мержа. 72704 5 legion 2008-06-19 01:02:48 +0400 (In reply to comment #3) > Сделал, но если в .gear/tags используются имена бранчей а не тегов, толку от этого > будет мало. > check_tag_name() не позволит использовать не тэги. Собственно в этом и проблема #15610. 72717 6 raorn 2008-06-19 01:29:13 +0400 (In reply to comment #5) > check_tag_name() не позволит использовать не тэги. И давно? См. напр. mutt1.5. 72720 7 legion 2008-06-19 02:10:40 +0400 (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 Кажется поэтому ты и можешь использовать имена бранчей. Либо я в чём-то сильно ошибаюсь. 72722 8 legion 2008-06-19 02:17:50 +0400 Хотя нужно внимательнее прочитать resolve_commit_name(). 72723 9 raorn 2008-06-19 02:22:24 +0400 Хм. $ 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 72725 10 legion 2008-06-19 02:27:19 +0400 (In reply to comment #9) > Хм. > > $ git check-ref-format tags/master && echo OK || echo ERR Вот-вот ... такое ощущение, что раньше check-ref-format проверял не только корректность имени, но и существование этого объекта. 72726 11 legion 2008-06-19 02:33:41 +0400 ну и разумеется: gear-update-tag "name" -> check_tag_name_from_command_line -> check_tag_name поэтому бранчи вместо тэгов можно создавать. 72727 12 raorn 2008-06-19 02:59:59 +0400 Мне бы хотелось чтобы это так и осталось... Иначе придётся лепить tip'ы на каждый бранч, что ещё неудобнее. 72763 13 legion 2008-06-19 13:13:43 +0400 Тут получается сложная ситуация ... бранч нарушает концепцию однозначной определённости коммита. Но такая конструкция уже используется и ты этому иллюстрация. Вообщем, нужно думать как это решать. P.S. Мне кажется, что всё-таки нужно запрещать использование бранчей. Это ломает всю идею этой утилиты. 72766 14 raorn 2008-06-19 13:34:16 +0400 Как раз наоборот. Эта утилита фиксирует имена тегов/бранчей на момент сборки. Мне удобно использовать бранчи, зачем усложнять людям жизнь? Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше шансов накосячить так, что никто этого не заметит (уже чинил такое). 72767 15 ldv 2008-06-19 13:39:03 +0400 (In reply to comment #14) > Как раз наоборот. Эта утилита фиксирует имена тегов/бранчей на момент > сборки. Мне удобно использовать бранчи, зачем усложнять людям жизнь? > Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше > шансов накосячить так, что никто этого не заметит (уже чинил такое). > Я тоже иногда использую бранчи, см. coreutils.git 72768 16 legion 2008-06-19 13:58:56 +0400 Угу. gear-update-tag фиксирует sha1 объекта при добавлении в .gear/tags. Тогда Лёшь, как быть с 16075#c3 ? P.S. Слова "мне так удобно" или "я так привык" за агрумент не считаю. 72769 17 legion 2008-06-19 14:07:17 +0400 Для меня загадка почему vsu так ограничил "diff: ...". К сожалению он на письма тоже не отвечает. 72770 18 raorn 2008-06-19 14:20:27 +0400 (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. Слова "мне так удобно" или "я так привык" за агрумент не считаю. Как насчёт слов "неувеличение энтропии"? Зачем делать два и более действий там, где достаточно одного? 72772 19 legion 2008-06-19 14:35:35 +0400 (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. 72776 20 legion 2008-06-19 14:48:01 +0400 Затеял исправление этой утилиты под наши реали: http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/gear-update-tag 72777 21 raorn 2008-06-19 14:49:07 +0400 (In reply to comment #19) > Почему же ты считаешь что при использовании бранчей от --verify толку будет > мало? Я не так выразился. Мало толку будет от использования --verify --tree-ish в том случае когда об'екты (бранчи или теги) из .gear/tags изменились. В бранч накоммитили или tip-тег подвинули - без разницы. Я не знаю как 100% определить случай, когда человек забыл подвинуть tip-тег, поэтому использую имена бранчей, кроме обязательного требования использовать только верионные tip-теги, но это уже помойму перебор. 72778 22 legion 2008-06-19 14:58:57 +0400 (In reply to comment #21) > Я не так выразился. Мало толку будет от использования --verify --tree-ish в том > случае когда об'екты (бранчи или теги) из .gear/tags изменились. В бранч > накоммитили или tip-тег подвинули - без разницы. А почему нельзя проверить sha1 из .gear/tags c sha1 на который указывает тег/бранч ? 72780 23 raorn 2008-06-19 15:03:52 +0400 (In reply to comment #22) > А почему нельзя проверить sha1 из .gear/tags c sha1 на который указывает тег/бранч ? Не понял вопроса. 72782 24 legion 2008-06-19 16:04:38 +0400 > Я не знаю как 100% определить случай, когда человек забыл подвинуть tip-тег, > поэтому использую имена бранчей, кроме обязательного требования > использовать только верионные tip-теги, но это уже помойму перебор. Так. Чтобы не толочь воду в ступе, можешь более детально поясинть, какую ситуацию нужно определить ? 72784 25 raorn 2008-06-19 16:52:36 +0400 .gear/rules: tar: master:. Если забыть обновить .gear/tags при сборке нового пакета соберётся предыдущая версия с новым спеком. gear не ругнётся, поскольку HEAD растёт из "старого master". 72785 26 legion 2008-06-19 16:59:32 +0400 (In reply to comment #25) > .gear/rules: > tar: master:. > > Если забыть обновить .gear/tags при сборке нового пакета соберётся предыдущая > версия с новым спеком. gear не ругнётся, поскольку HEAD растёт из "старого master". > Т.е. если пользователь передвинул тег перечисленный в .gear/tags и не сказал gear-update-tag ? 72786 27 raorn 2008-06-19 17:09:13 +0400 Именно. 72787 28 legion 2008-06-19 17:19:15 +0400 (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. Разве нет ? 72788 29 raorn 2008-06-19 17:34:19 +0400 Ты издеваешься, да? Именно это и делает gear-update-tag --verify. 72789 30 legion 2008-06-19 17:40:25 +0400 (In reply to comment #29) > Ты издеваешься, да? Именно это и делает gear-update-tag --verify. Именно. Я к тому что я не очень понимаю проблемы 16075#c25. Разве что отсутствия такой же проверки в gear. 72790 31 raorn 2008-06-19 17:47:09 +0400 Ты всё-таки надо мной издеваешься. Зачем ты это делаешь? 72791 32 legion 2008-06-19 17:55:43 +0400 (In reply to comment #31) > Ты всё-таки надо мной издеваешься. Зачем ты это делаешь? Я вижу мы с тобой никак не можем найти общий язык. Я этот флейм прекращаю. Твои изменения я смерджил в gear-next. Дима их может взять либо у меня, либо у тебя. Сс: -legion@ 73034 33 ldv 2008-06-23 15:22:08 +0400 (In reply to comment #15) > (In reply to comment #14) > > Как раз наоборот. Эта утилита фиксирует имена тегов/бранчей на момент > > сборки. Мне удобно использовать бранчи, зачем усложнять людям жизнь? > > Выстрелить себе в ногу можно и тегами вида BRANCHNAME-tip, только тут ещё больше > > шансов накосячить так, что никто этого не заметит (уже чинил такое). > > Я тоже иногда использую бранчи, см. coreutils.git Погорячился. Не использую я бранчи в .gear/rules 73042 34 legion 2008-06-23 16:04:05 +0400 (In reply to comment #33) > Погорячился. Не использую я бранчи в .gear/rules А это не важно. Если есть хоть один человек, то нет гарантии что он такой один. Я даже не знаю как долго у нас разрешено такое поведение. 74137 35 vsu 2008-07-17 20:43:45 +0400 По поводу разрешения использования бранчей вместо тегов, как сделано в 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 почему-то его не отлавливает. 76151 36 legion 2008-08-24 01:39:55 +0400 Исправлено. Закрываю. 76152 37 legion 2008-08-24 01:41:12 +0400 Ключ добавлен.