нужно чтобы обрабатывать импорт __до__ git add (в конкретном случае, разжать некоторые вложенные архивы) пример реализации (тестирован, работает) http://git.altlinux.org/people/viy/packages/?p=gear.git;a=commit;h=6b3306fa990ce45447cabb0ddc3bbd12e3bf9e46
Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал вложенные архивы. То что вы предлагаете больше похоже на быстрый хак.
> Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал > вложенные архивы. кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом виде. кроме того, у скрипта может быть и другое полезное применение.
(В ответ на комментарий №2) > > Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал > > вложенные архивы. > кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом > виде. > > кроме того, у скрипта может быть и другое полезное применение. т.е. опция для разжатия вложенных архивов и опция запуска скрипта друг другу не мешают, их можно реализовать независимо. Это разная функциональность, вообще говоря.
Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще выполнить gear-update несколько раз для необходимых архивов внутри. Что экономит этот патч ? один вызов git-add ?
(В ответ на комментарий №4) > Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще > выполнить gear-update несколько раз для необходимых архивов внутри. скажем так, там несколько сот .ppd.gz файлов для разных моделей принтеров. их я разжимаю до просто ppd, так мне легче отслеживать изменения. > Что экономит этот патч ? один вызов git-add ? как видим, гораздо больше, чем один вызов git-add.
Для этой задачи не нужно патчить gear-update. Последовательность gear-update; find -name '*.ppd.gz' |xargs -r gunzip; git add ... будет эффективнее.
(В ответ на комментарий №6) > Для этой задачи не нужно патчить gear-update. Последовательность > > gear-update; find -name '*.ppd.gz' |xargs -r gunzip; git add ... > будет эффективнее. gear-update уже сделал git add на *.ppd.gz файлы. Если выполнять операции после gear-update, то дополнительно их придется удалить из индекса и вызвать git gc. проще сразу обойтись без gear-update :( Скрипт становится намного проще и понятнее, если не производит манипуляций с индексом. В чем проблема иметь в gear-update дополнительную опцию?
если не нравится название опции, можно поменять на любоее другое по вкусу. мне без разницы.
Операции над индексом не обязательно производить т.к. сжатых файлов не будет. Следующий за gear-update git-commit закоммитит правильные файлы. Я считаю саму идею встраивания произвольного кода в gear-update хаком... к тому же ради экономии на git-add. Эта утилита задумывалась для того, чтобы обновлять часть дерева из файла архива. Дополнительные танцы над новыми данными она не производит. Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками. Если Дима считает нужным, то пусть вносит подобные изменения, но лично я против.
(В ответ на комментарий №9) > Операции над индексом не обязательно производить т.к. сжатых файлов не будет. > Следующий за gear-update git-commit закоммитит правильные файлы. но в индексе останется мусор # deleted: хххх который придется вычищать :( > Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками. Если утилита позиционируется как стандартная дистрибутивная, то она и должна быть комбайном, который поддерживает возможности, которые автору 100 лет в обед не нужны, но нужны другим людям. Иначе ей место в другом пакете, в legion-utils. > Если Дима считает нужным, то пусть вносит подобные изменения, но лично я > против. :(
(В ответ на комментарий №10) > # deleted: хххх > который придется вычищать :( Это можно вычищать лишь для эстетики. > Если утилита позиционируется как стандартная дистрибутивная, то она и должна > быть комбайном, Нет.
(In reply to comment #9) > Я считаю саму идею встраивания произвольного кода в gear-update хаком... Насколько я понимаю, в сам gear-update никто не предлагает встраивать запуск произвольного кода. > к тому же ради экономии на git-add. Если после запуска gear-update дерево надо подчищать, то проще обновлять дерево вручную. Все удобство от использования gear-update образуется в результате того, что у этой утилиты простой интерфейс и она не оставляет за собой хвостов. > Эта утилита задумывалась для того, чтобы обновлять > часть дерева из файла архива. Дополнительные танцы над новыми данными она не > производит. Вопрос в том, как определять понятие "обновлять часть дерева". Например, если внутри архива есть другой архив, то кто-то может сказать, что этот внутренний архив тоже надо распаковать. Возможно, gear-update стоит обучить работать в режиме --deep=N, где N это глубина рекурсии по расжатию и распаковке. > Не нужно превращать утилиту в комбайн к тому же с внешними > обработчиками. Я не вижу во внешних обработчиках ничего заведомо плохого. Если от этого интерфейса кому-то может быть польза, а сам по себе он ничего не портит, то зачем от него отказываться? Кстати, я придумал еще один пример кастомного обработчика, который в принципе может когда-нибудь понадобиться: это удаление нежелательных файлов по какому-нибудь критерию (файлы с недопустимыми условиями распространения, бекап-файлы, скомпилированные файлы, и т.п.) Было бы логично, если бы кастомный обработчик находился в том же репозитории, что и обновляемые архивы, иначе будет непонятно, каким образом эти архивы были обновлены. К сожалению, это требование невозможно сделать обязательным (просто потому, что кастомный обработчик все равно выполняет произвольный код из произвольного места). (In reply to comment #8) > если не нравится название опции, можно поменять на любоее другое по вкусу. > мне без разницы. Мне вообще кажется, что это было бы удобнее настраивать через $GIT_DIR/config, см. раздел CONFIGURATION в gear-import(1). Тогда кастомные обработчики естественным образом (через gear-update) встроились бы и в gear-import.
(В ответ на комментарий №12) > Насколько я понимаю, в сам gear-update никто не предлагает встраивать запуск > произвольного кода. В данном случае я имел в виду запуск произвольной программы. > Если после запуска gear-update дерево надо подчищать, то проще обновлять дерево > вручную. Все удобство от использования gear-update образуется в результате > того, что у этой утилиты простой интерфейс и она не оставляет за собой хвостов. Я проверил результат выполнения gear-update несколько раз на одном и том же дереве (второй запуск был разумеется с --force) и никаких deleted хвотов не обнаружил. Таким образом, рекурсивно распаковывать архивы можно и эстетика не страдает. Проблема только в том, что разжимая архив внутри дерева нет возможности его сразу удалить после распаковки. Эту проблему можно решить. > Возможно, gear-update стоит обучить работать в режиме --deep=N, где N это > глубина рекурсии по расжатию и распаковке. Примерно эту идею я выдвигал в #1 :) Но после от неё отказался т.к. пользователь не обязательно хочет распаковывать все архивы внутри N. Эту ситуацию придётся разрешать дополнительными телодвижениями в виде шаблонов имён или ещё как-то. На мой взгляд, проще и правильнее предоставить пользователю возможность запускать gear-update внутри дерева. Тогда пользователь сможет рекурсивно разжать только нужные архивы. > Я не вижу во внешних обработчиках ничего заведомо плохого. Если от этого > интерфейса кому-то может быть польза, а сам по себе он ничего не портит, то > зачем от него отказываться? Обоснование такого кастомного обработчика не достаточное в этой баге. > Кстати, я придумал еще один пример кастомного обработчика, который в принципе > может когда-нибудь понадобиться: это удаление нежелательных файлов по > какому-нибудь критерию (файлы с недопустимыми условиями распространения, > бекап-файлы, скомпилированные файлы, и т.п.) А вот это уже более конкретный use-case. Почему тебя не устраивают .gitignore или .git/info/exclude ?
(In reply to comment #13) > Я проверил результат выполнения gear-update несколько раз на одном и том же > дереве (второй запуск был разумеется с --force) и никаких deleted хвотов не > обнаружил. Таким образом, рекурсивно распаковывать архивы можно и эстетика не > страдает. Конечно, можно, но сейчас есть два ограничения. > Проблема только в том, что разжимая архив внутри дерева нет возможности его > сразу удалить после распаковки. > Эту проблему можно решить. Это первое ограничение. > На мой взгляд, проще и правильнее предоставить пользователю возможность > запускать gear-update внутри дерева. Тогда пользователь сможет рекурсивно > разжать только нужные архивы. Необходимость запуска gear-update более одного раза для полного обновления дерева из одного тарболла - это другое ограничение, если иметь в виду gear-import, который запускает gear-update ровно один раз. > > Кстати, я придумал еще один пример кастомного обработчика, который в принципе > > может когда-нибудь понадобиться: это удаление нежелательных файлов по > > какому-нибудь критерию (файлы с недопустимыми условиями распространения, > > бекап-файлы, скомпилированные файлы, и т.п.) > > А вот это уже более конкретный use-case. > Почему тебя не устраивают .gitignore или .git/info/exclude ? Это, как видно, менее конкретный и менее удачный пример; для его реализации механизма gitignore(5) должно быть достаточно.
(В ответ на комментарий №14) > Это, как видно, менее конкретный и менее удачный пример; для его реализации > механизма gitignore(5) должно быть достаточно. Кстати: $ gear-update --help |grep exclude= --exclude=PATTERN exclude files matching posix-egrep regular expression PATTERN;
(В ответ на комментарий №14) > > Проблема только в том, что разжимая архив внутри дерева нет возможности его > > сразу удалить после распаковки. > > Эту проблему можно решить. > > Это первое ограничение. Это исправим. В любом случае это полезная возможность. > Необходимость запуска gear-update более одного раза для полного обновления > дерева из одного тарболла - это другое ограничение, Я не считаю это ограничением. Это поведение идентично tar/zip/gzip, которые не пытаются распаковать архивы внутри архива. > если иметь в виду > gear-import, который запускает gear-update ровно один раз. Это "ограничение" тоже можно попробовать решить. Устранение подобных ограничений более конструктивная задача за которую стоит браться.
(In reply to comment #16) > (В ответ на комментарий №14) > > > Проблема только в том, что разжимая архив внутри дерева нет возможности его > > > сразу удалить после распаковки. > > > Эту проблему можно решить. > > > > Это первое ограничение. > > Это исправим. В любом случае это полезная возможность. Договорились. > > Необходимость запуска gear-update более одного раза для полного обновления > > дерева из одного тарболла - это другое ограничение, > > Я не считаю это ограничением. Это поведение идентично tar/zip/gzip, которые не > пытаются распаковать архивы внутри архива. > > > если иметь в виду > > gear-import, который запускает gear-update ровно один раз. > > Это "ограничение" тоже можно попробовать решить. > > Устранение подобных ограничений более конструктивная задача за которую стоит > браться. Если рассматривать gear-update как простой низкоуровневый инструмент, тогда алгоритм настраиваемого итерационного запуска gear-update должен быть реализован за его пределами. Поскольку gear-import использует gear-update, можно предложить реализовать этот алгоритм в gear-import.
(В ответ на комментарий №16) > Устранение подобных ограничений более конструктивная задача за которую стоит > браться. А исходное пожелание по поводу обработчика?
(В ответ на комментарий №17) > Договорились. Уже в процессе. > Если рассматривать gear-update как простой низкоуровневый инструмент, тогда > алгоритм настраиваемого итерационного запуска gear-update должен быть > реализован за его пределами. Поскольку gear-import использует gear-update, > можно предложить реализовать этот алгоритм в gear-import. Да. Мне это кажется более правильным.
(В ответ на комментарий №18) > А исходное пожелание по поводу обработчика? Ваша задача должна решаться не обработчиком.
