Bug 31851

Summary: add exclude to diff options
Product: Sisyphus Reporter: Anton Farygin <rider>
Component: gearAssignee: Ivan Zakharyaschev <imz>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: boyarsh, cas, glebfm, grenka, grenka, imz, ldv, legion, nbr, placeholder, rider, slev, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   

Description Anton Farygin 2016-03-02 11:53:15 MSK
Было бы неплохо добавить к diff в gear-rules возможность указывать exclude каталогам.

Мне это нужно для того, что бы в патч не попадал каталог .gear
например:
diff: v@version@:. . exclude=.gear
Comment 1 Ivan Zakharyaschev 2018-07-20 08:08:28 MSK
Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить).

Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка alt). Пусть только коммиты с тестами не пугают. По сути они, конечно, работают и написаны для большинства случаев. Но остаётся привести в лучший вид. Мне не понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу дедуплицировать код тестов.

Будет полезно не только для diff, но правил типа tar. Пример:

diff: v@version@:. . -- . :!.gear

tar: v@version@:. -- . :!.gear

Используется синтаксис (с магией), понимаемый командами Git с некоторый пор: git cmd ... -- paths..

Из-за ошибки в Git приходится писать не как в примерах (с точкой), а со звёздочкой (только для правил типа tar, а не diff; т.е. ошибка есть в работе git archive, но не git diff):

tar: v@version@:. -- * :!.gear

Приветствуется ознакомление заинтересованных.
Comment 2 Grigory Ustinov 2018-07-20 10:04:15 MSK
(В ответ на комментарий №1)
> Мне не
> понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу
> дедуплицировать код тестов.

Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема?

"Что сделано не вовремя, сделано понапрасну" (с) Френсис Бэкон
Comment 3 Ivan Zakharyaschev 2018-07-20 10:12:49 MSK
(In reply to comment #2)
> (В ответ на комментарий №1)
> > Мне не
> > понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу
> > дедуплицировать код тестов.
> 
> Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема?

Просто этот пакет кто-то из acl будет смотреть и одобрять.

Я уже этим сообщением предложил посмотреть. И в тот момент, когда кто-то будет готов одобрить, можно будет отправить текущее состояние.

Пока что переписываю дополнительные тесты с помощью дополнительных функций в том  же файле (вызывающих основную), без копирования файла. Частично это сделано, можно увидеть в моих опубликованных коммитах.
Comment 4 Ivan Zakharyaschev 2018-07-20 16:06:57 MSK
Можно будет попробовать в task 210568
Comment 5 Dmitry V. Levin 2018-07-20 16:19:34 MSK
(In reply to comment #1)
> Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить).
> 
> Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка
> alt).

Там специально commit messages в другом стиле выполнены?
Некоторые по ширине даже у меня на экране не помещаются.
Comment 6 Ivan Zakharyaschev 2018-07-20 16:29:22 MSK
(In reply to comment #5)
> (In reply to comment #1)
> > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить).
> > 
> > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка
> > alt).
> 
> Там специально commit messages в другом стиле выполнены?
> Некоторые по ширине даже у меня на экране не помещаются.

Нет, я не обращал внимание. Посмотрю.

Пользуясь случаем, хочу рассказать, что на i586 произошла ошибка в задании 210568:

gear-update: /usr/src/tmp/run.lcG0esBBa/.git/.work/initial-import.cpio.zst: unrecognized source type: 
[FAIL] (gear_update_subdir_sub_cpio_zst_cwd)
Comment 7 Dmitry V. Levin 2018-07-20 16:44:59 MSK
(In reply to comment #6)
> Пользуясь случаем, хочу рассказать, что на i586 произошла ошибка в задании
> 210568:
> 
> gear-update: /usr/src/tmp/run.lcG0esBBa/.git/.work/initial-import.cpio.zst:
> unrecognized source type: 
> [FAIL] (gear_update_subdir_sub_cpio_zst_cwd)

http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0720/success/gear-2.2.0-alt1
http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0719/error/gear-2.2.0-alt1.zst
http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0717/success/gear-2.2.0-alt1.zst
...
http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0701/success/gear-2.2.0-alt1.zst
Comment 8 Ivan Zakharyaschev 2018-07-20 16:56:14 MSK
(In reply to comment #5)
> (In reply to comment #1)
> > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить).
> > 
> > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка
> > alt).
> 
> Там специально commit messages в другом стиле выполнены?
> Некоторые по ширине даже у меня на экране не помещаются.

Переписал. Ещё дописываю обновление документации. Есть ли возражения против всего остального?

(Пока с этим копался, появилась мысль, что тесты можно было бы покороче записать, с меньшми повторениями, в т.ч. старые, но я не стремлюсь переписать их к ближайшему релизу.)
Comment 9 Dmitry V. Levin 2018-07-20 20:25:46 MSK
В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов.

Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем нечитабельно". :)
Comment 10 Ivan Zakharyaschev 2018-07-21 01:07:31 MSK
(In reply to comment #9)
> В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic
> paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов.

Поправил, и отправил на сборку. Это уже все изменения с моей стороны на данный момент, больше ничего добавлять перед предложеннымм релизом не планирую по своей задумке. Учту замечания.

> Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем
> нечитабельно". :)

Я это тоже вижу, но быстро без переосмысления и перестркутурирования не могу поменять сейчас.
Comment 11 Grigory Ustinov 2018-09-18 17:57:27 MSK
Ping?
Comment 12 Dmitry V. Levin 2018-09-18 20:13:25 MSK
Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня устраивают.
Изменения тестов я просто не в состоянии прочитать.
Comment 13 Alexey Gladkov 2018-09-18 23:34:23 MSK
Я попробую их вычитать.
Comment 14 Alexey Gladkov 2018-09-19 18:47:23 MSK
(В ответ на комментарий №12)
> Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня
> устраивают.

Дим, я чего-то не заметил и gear стал не posix совместимым проектом ?
С каких пор мы начали массивы использовать ?

http://git.altlinux.org/people/imz/packages/gear.git?p=gear.git;a=commitdiff;h=d966f99507e46836b6c8be43daf93a9dd67764c7
Comment 15 Alexey Gladkov 2018-10-01 22:15:03 MSK
Я не против предложенных изменений. Я против реализации. Этот проект никогда не использовал башизмы. Я уверен, что эти изменения можно реализовать без их использования.
Comment 16 Grigory Ustinov 2018-10-01 23:14:05 MSK
(В ответ на комментарий №15)
> Я не против предложенных изменений. Я против реализации. Этот проект никогда не
> использовал башизмы. Я уверен, что эти изменения можно реализовать без их
> использования.

Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в конце строки у вас вызывает эпилептический припадок, я даже готов понять, что 10 строк коммит-мессаджа должны описывать 3 строчки кода.

Объясните мне, почему башизмы это плохо? Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое изменение в сборочницу? Ведь решение этой баги позволит не паковать блобы в српм, например, с помощью одной лишь строчки в rules, а не созданием лишней ветви в гите и постоянным мерджем при обновлениях.
Comment 17 Ivan Zakharyaschev 2018-10-01 23:42:19 MSK
(In reply to comment #15)
> Я не против предложенных изменений. Я против реализации. Этот проект никогда не
> использовал башизмы. Я уверен, что эти изменения можно реализовать без их
> использования.

Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не очень желательно, потому что пользователи могут быть на разных системах.

Тут после прочтения коммента ещё пока не успел переписать.

Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить отклик.
Comment 18 Alexey Gladkov 2018-10-02 02:03:29 MSK
(В ответ на комментарий №17)
> Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю
> или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar
> (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не
> очень желательно, потому что пользователи могут быть на разных системах.

Спасибо за понимание.

> Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то
> ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить
> отклик.

Если они и есть (сходу их не смог найти), то это явно бага. Если вы их видели,
то напишите.
Comment 19 Alexey Gladkov 2018-10-02 02:37:49 MSK
(В ответ на комментарий №16)
> Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в
> конце строки у вас вызывает эпилептический припадок, я даже готов понять, что
> 10 строк коммит-мессаджа должны описывать 3 строчки кода.

Судя по вашему комментарию, вы этого не понимаете.

> Объясните мне, почему башизмы это плохо?

Вы ограничиваете проект с posix-compatible, до bash-specific.

Башизмы хорошы там, где они приняты. В etcnet с ними никто не борется т.к. проект изначально был написан на bash. Нужно поминть, что bashism это определённый диалект шелла. Такой же как zshism. Ваше возмущение можно сравнить с возмущением, что кто-то отвергает zsh-speific код, а он такой локаничный и реализует что-то полезное.

Любой такой диалект уменьшает количесто возможных интерпретаторов шелла до одного. Башизмы можно использовать только в bash и даже не все и не во всех версиях баш.

> Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое
> изменение в сборочницу?

Понятие "довольно необходимые" очень относительно. Любое изменение довольно необходимо. Повторю, я совершенно не против предложенного функционала, но я против того как это реализовано. Утрируя я могу сказать, что я также против довольно необходимых изменений c использованием python или ruby в этом проекте.

Это моя позиция. Она может отличаться от позиции Димы.

P.S. Это оффтопик для этой баги. Если вы хотите  это обсудить, то пишите мне лично или в рассылку.
Comment 20 Anton Farygin 2018-10-02 07:37:07 MSK
Да согласен с Лёшей - использование расширений bash в именно этом проекте недопустимо.

gear может работать без hasher и не на альте. Лучше эту фичу сохранить.

Правда, ему для полного счастья ещё требуется rpm от альта, но это уже немного другой разговор.
Comment 21 Dmitry V. Levin 2019-06-19 01:42:26 MSK
*** Bug 35219 has been marked as a duplicate of this bug. ***
Comment 22 Anton Farygin 2020-02-12 13:41:53 MSK
Если Ваня этим не занимается, то давайте попросим автора gear добавить эту фичу.
Comment 23 Stanislav Levin 2020-02-12 13:49:41 MSK
Очень интересная фича.
Можно узнать про ее статус?
Comment 24 Ivan Zakharyaschev 2020-02-12 14:06:17 MSK
(In reply to Stanislav Levin from comment #23)
> Очень интересная фича.
> Можно узнать про ее статус?

У меня в целом всё готово было (аз я уже просил approve), только legion@ не хотел видеть там в коде один bashism, а также тестов стало больше и их задание, к сожалению, менее вразумительно стало выглядеть. (По-моему, замечание от ldv@ было.)
Comment 25 Dmitry V. Levin 2020-12-27 14:39:58 MSK
Apparently, diff exclude= option was implemented in

* Sat Dec 19 2020 Dmitry V. Levin <ldv@altlinux> 2.4.0-alt1
- Added "exclude=" option to "diff" directive
  (by Vladimir D. Seleznev, Alexey Gladkov, and me).
Comment 26 Anton Farygin 2020-12-27 19:42:58 MSK
Спасибо, а это будет работать для всех stable веток ?
Comment 27 Dmitry V. Levin 2020-12-27 19:53:46 MSK
(In reply to Anton Farygin from comment #26)
> Спасибо, а это будет работать для всех stable веток ?

Тестирование на сборочнице пока проходит успешно.
Comment 28 Anton Farygin 2021-03-15 12:30:22 MSK
Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, когда эта опция была бы полезна для директивы tar

Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить отдельный FR ?
Comment 29 Dmitry V. Levin 2021-03-15 15:02:43 MSK
(In reply to Anton Farygin from comment #28)
> Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай,
> когда эта опция была бы полезна для директивы tar
> 
> Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить
> отдельный FR ?

Концептуально exclude для архивов (tar, zip) ничему не противоречит,
сложность реализации аналогична exclude для dif, на самом деле даже проще, потому что можно использовать реализацию exclude для diff в качестве примера.

Для отслеживания лучше завести отдельный FR.
Comment 30 Alexey Gladkov 2021-03-15 15:28:23 MSK
(Ответ для Anton Farygin на комментарий #28)
> Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай,
> когда эта опция была бы полезна для директивы tar
> 
> Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить
> отдельный FR ?

Не сложно. Лучше открой новый баг и повесь на меня.