ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [FR] gear-update-tag: add "verify" mode | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sir Raorn <raorn> |
| Component: | gear | Assignee: | Dmitry V. Levin <ldv> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | glebfm, ldv, legion, placeholder, vsu, vvk |
| Version: | unstable | Keywords: | patch |
| Hardware: | all | ||
| OS: | Linux | ||
| URL: | http://git.altlinux.org/people/raorn/packages/?p=gear.git;a=shortlog;h=refs/heads/verify-tag | ||
|
Description
Sir Raorn
2008-06-17 21:05:53 MSD
Параметр --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 почему-то его не отлавливает. Исправлено. Закрываю. Ключ добавлен. |
