Доступен (https://github.com/blog/2360-git-2-13-has-been-released) выпуск распределенной системы управления исходными текстами Git 2.13.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st.../), Android (https://android.googlesource.com/), LibreOffice (http://cgit.freedesktop.org/libreoffice), Systemd (http://cgit.freedesktop.org/systemd), X.Org (http://cgit.freedesktop.org/xorg), Wayland (http://cgit.freedesktop.org/wayland), Mesa (http://cgit.freedesktop.org/mesa/), GStreamer (http://cgit.freedesktop.org/gstreamer), Wine (http://source.winehq.org/git/wine.git), Debian (http://anonscm.debian.org/gitweb), DragonFly BSD (http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary), Perl (http://perl5.git.perl.org/perl.git), Eclipse (http://git.eclipse.org), GNOME (http://git.gnome.org/browse/), KDE (https://projects.kde.org/projects), Qt (https://code.qt.io/cgit/), Ruby on Rails (https://github.com/rails/rails), PostgreSQL (http://git.postgresql.org/gitweb/), VideoLAN (http://git.videolan.org), PHP (http://git.php.net/), Python (https://github.com/python/cpython), Xen (http://xenbits.xen.org/gitweb/), Minix (http://git.minix3.org/).
По сравнению с прошлым выпуском в новую версию принято 729 изменения, подготовленных при участии 65 разработчиков, из которых 15 впервые приняли своё участие в разработке. Основные изменения (https://github.com/git/git/blob/v2.13.0/Documentation/RelNot...):
- Устранена уязвимость (https://git.kernel.org/pub/scm/git/git.git/commit/?id=3ec804...) (CVE-2017-8386 (https://security-tracker.debian.org/tracker/CVE-2017-8386)), которая позволяет запустить внешние команды при подсоединении к репозиторию через SSH в режиме "git-shell" (оболочка, ограничивающая ssh-клиентов только операциями с git). В частности, при выполнении "git upload-pack --help" запускается интерактивный интерфейс для постраничного просмотра подсказки, из которого можно вызвать произвольные программы на стороне удалённой системы. Конфигурации, использующие git-shell вместе с gitolite проблеме не подвержены;- Добавлен код для выявления в Git-репозиториях известных коллизий (https://www.opennet.me/opennews/art.shtml?num=46091) в хэшах SHA-1, который поможет защититься от возможных атак (https://www.opennet.me/opennews/art.shtml?num=46232) через подмену репозитория. В дальнейшем планируется избавиться (https://github.com/git/git/compare/c703555cc89cf6aedf549a123...) от жёсткой привязки Git от SHA-1 и
добавить (https://docs.google.com/document/d/18hYAQCTsDgaFUo-VJGhT0Uqy...) опциональную поддержку SHA3-256, которая сможет применяться параллельно с SHA-1. Таким образом, переведённый на SHA3-256 локальный репозиторий сможет взаимодействовать с Git-серверами (как минимум на уровне push/fetch), поддерживающими только SHA-1, а пользователи смогут одновременно использовать идентификаторы объектов SHA-1 и SHA3-256;- Расширены возможности по использованию шаблонов (https://git-scm.com/docs/gitglossary#gitglossary-aiddefpaths...) файловых путей в командах git. В частности, добавлен сокращённый оператор для исключения путей "^", который может использоваться вместо выражения ":(exclude)" и вместо ранее применяемого сокращения "!", которое требовало экранирования блока кавычками. Например, если раньше для выполнения выборки файлов с расширениями, отличными от ".c", требовалось выполнить:
git grep this.is.a -- src ':(exclude)*.c'
или
git grep this.is.a -- src ':!*.c'
то сейчас можно упростить конструкцию до
git grep this.is.a -- src :^*.c
Кроме того, в новой версии представлен новый оператор ":(attr)", который позволяет выбрать файлы, соответствующие заданному списку атрибутов. Например, для вывода файлов, хранимых в LFS (хранилище больших бинарных данных) можно выполнить:
git ls-files ':(attr:filter=lfs)'
При желании можно определить и привязать свои атрибуты и комбинировать attr с другими операторами:
echo 'libfoo/ vendored' >>.gitattributes
echo 'imported-tool/ vendored' >>.gitattributes
git grep -i license -- ':(attr:vendored)'
git grep foobar -- ':(exclude,attr:vendored)'- В файлах конфигурации появилась возможность применения условных операторов через которые можно организовать применение разных опций для разных групп репозиториев путём включения дополнительных блоков конфигурации при наличии определённых файловых путей. Например, можно указать в настройках один email для внутренних рабочих проектов и другой для использования при работе со сторонним открытым кодом, что позволит избежать казусов в случае если новый репозиторий не был настроен должным образом.
~/.gitconfig:
[includeIf "gitdir:~/work/"]
path = .gitconfig-work
[includeIf "gitdir:~/play/"]
path = .gitconfig-play~/.gitconfig-work:
[user]
name = Serious Q. Programmer
email = serious.programmer@business.com~/.gitconfig-play:
[user]
name = Random J. Hacker
email = hack75@0dayf0r4ou.com- В команде "git log" по умолчанию активирован режим "--decorate=auto", при котором коммиты, указывающие непосредственно на ветку или тег, выделяются и выводятся c именем ветки;
- Код организации вывода в "git branch" переведён на использование системы ref-filter, которая также используется в "git for-each-ref"
и "git tag", что позволяет использовать в "git branch" аналогичные опции форматирования вывода ("--format=");- В "git branch", "git tag" и "git for-each-ref" добавлена опция "--no-contains", которая дополняет опцию "--contains" и позволяет запросить теги или ветки, в которых отсутствует определённая ошибка или исправление;
- В "git stash save" добавлена поддержка шаблонов файловых путей;
- Спецназвания веток @{upstream}, @{u} и @{push} теперь не чувствительны к регистру символов (часто, после ввода "{" разработчики допускали опечатку и вводили первый символ с большой буквы);
- В дополнение к реализованной в прошлых выпусках возможности рекурсивного обхода субмодулей в командах checkout, grep и ls-files, в Git 2.13 реализован вывод дополнительной информации о субмодулях при выполнении команды "git status --short".
URL: http://lkml.iu.edu/hypermail/linux/kernel/1705.1/01336.html
Новость: http://www.opennet.me/opennews/art.shtml?num=46523
А чем разрабов git не устраивает ~/.config/git по дефолту? Все вечно стремятся нагадить в корневую своими конфигурационными файлами
Тем, что всем нужны разные конфигурации. Ваш К.О..git/config не клонируется, само дерево - клонируется. То есть в .git/config ложатся приватные настройки репозитория, в дерево - то, что должно быть у всех
> Тем, что всем нужны разные конфигурации. Ваш К.О.
> .git/config не клонируется, само дерево - клонируется. То есть в .git/config ложатся
> приватные настройки репозитория, в дерево - то, что должно быть у
> всехЯ пытался уловить связь твоего ответа с заданным вопросом. И не уловил.
Сорри. Спать мне надо больше, совсем торможу сегодня.Перепутал .config/git с .git/config
А в каком стандарте написано, что именно там находится дефолт?
> А в каком стандарте написано, что именно там находится дефолт?В XDG Base Directory Specification https://specifications.freedesktop.org/basedir-spec/basedir-...
Да, там действительно так написано. Только вот непонятно мне, почему консольная утилита git должна следовать стандарту для десктопных окружений?
> Только вот непонятно мне, почему теплая утилита
> git должна следовать стандарту для мягких окружений?fix.
https://www.freedesktop.org/wiki/Software/
Потому что это разумно? Я понимаю, если бы таких стандартов был пяток, и в гите бы выбрали не тот, что кому-то нравится. Но зачем хомяк забивать?
> Да, там действительно так написано. Только вот непонятно мне, почему консольная утилита
> git должна следовать стандарту для десктопных окружений?А почему бы и нет? Если вместо кучи дот-файлов в хомяке будет несколько поддиректорий, IMHO будет только лучше. Да и бэкапить удобнее.
> Да и бэкапить удобнее.Конечно. Вместо одного .git бэкапить тройку .config/git, .cache/git, .local/share/git. Красота!
> Конечно. Вместо одного .git бэкапить тройку .config/git, .cache/git, .local/share/git.
> Красота!
> .cache/git,На кой бэкапить кэш-то? 0_o
Зачем? .config, .local бэкапятся целиком, .cache так же целиком игнорится.Ну, или исключения для некоторых пишутся, но один хрен большинство уходит в бэкап.
>почему консольная утилита git должна следовать стандарту для десктопных окружений?Чтобы в хомяке сам чёрт ногу не сломал.
В стандарте от freedesktop:
https://www.freedesktop.org/wiki/Specifications/basedir-spec/
Уже пять лет как устраивает https://github.com/git/git/blob/master/Documentation/RelNote...
> часто, после ввода "{" разработчики допускали опечатку и вводили первый символ с большой буквыно зачем они это делали?
и почему именно первый символ?
где логика?
В том, что { вводится с зажатым Shift, часто не успеваешь отпустить
Потому что в последовательности @{u} три символа и четырёх набираются с шифтом. И я рад, что теперь мне теперь будет проще зажать его и набрать все четыре символа @{U}
Никогда этого не понимал. Всегда, любой текст в любых скобках набираю вот так, и проблем не знаю: открывающая скобка→закрывающая скобка→курсор между ними→текст в скобках. В случае с @{u} три символа подряд набираются с зажатым шифтом, потом шифт безболезненно отпускается
Не всем нравиться стоя в гамаке.
> Не всем нравиться стоя в гамаке.А, совершенно внезапно, еще есть раскладки, в которых шифт для этого вообще не требуется.
Хотя конечно прикольно - с одной стороны такие вот как вы, любят повозмущаться "они не в курсе, что есть не только ASCII|лат.буквы, но и другие кодировки|графемы|нужное вставить!", с другой стороны, даже не желают задумываться о том, что их раскладка далеко не единственная в мире )
Забавно, что столько коммитов в этот ваш гит, а он все так же ощущается как куча костылей^Wскриптов-на-перле-и-баше, склеенных друг с другом изолентой.
Другое дело hg на пистоне... зато не на перле.
Не всем дана способность управлять столь большим количеством степеней свободы который дает perl.
"Всех неосиляторов в биореакт\^W питон." (с)
Да уж получше. Целостность меркуриала против заплаточности гит.
знали бы вы, сколько "костыли на перле" жизней спасли)
А сколько погубили?
А скольким пофиг?
Любой проект написанный "для себя", "под определенную задачу" или просто "для себя" всегда выглядит как набор костылей когда "вырастает из своих штанишек". То что вы не понимаете этого говорит о вас что вы либо админ локалхоста, либо хеллоуворлдщик.
Я это понимаю, и, собственно, этот факт констатировал в своем комментарии. Мне просто грустно, что при наличии грамотно реализованных инструментов (hg и другие) все всё равно пользуются этим "выросшим из штанишек" просто потому что "так заведено".
Дело не в том что "так заведено", а потому что пользовать git - это круто, а hg - уныло.
Минусуют - значит не понимают. Тогда я уточню.
Все идет от инструментов. Вот hg - уныло потому что сам python - это уныло, и это перекинулось на hg.Если python2 было что-то вроде "пиитоон", то есть медленно и неповоротливо, то python3 - это уже "пииитооон", то есть еще медленней и неповоротливей. Поэтому python - синоним слова "уныло" и "бесперспективно".
Хаскель, например, это круто. Си - это круто. Perl - это круто. Erlang, lisp, asm, oberon - это все тоже круто!! PHP - помойка. Java - это не круто и не прикольно, но серьезно.
А python - это уныло и самое важное - бесперспективно (фатальный недостаток).
Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только вендузятники любят за черепашку, больше ничего в нем хорошего нет. Работаешь с ним всегда, будто бегаешь в болотных сапогах.
> Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только
> вендузятники любят за черепашку, больше ничего в нем хорошего нет. Работаешь
> с ним всегда, будто бегаешь в болотных сапогах.Именно что лучше спроектирован, продуман. В отличии от зоопарка заплаток.
>> Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только
> Именно что лучше спроектирован, продуман. В отличии от зоопарка заплаток.Да, проектирование на питонах https://glandium.org/blog/?p=3835 это главное.
Причём тут какие-то штанишки? Вполне нормальный юниксвейный подход: основной функционал на C, вспомогательные инструменты, весь смысл которых в последовательном запуске бинарей с разными опциями, на шелле.
При том что речь была про архитектуру, а не ее реализацию. Еще даже не хеллоуворлдщик?
Так и я про архитектуру, джун. Это называется расширяемость: новый функционал легко добавляется с помощью скриптов/бинарей, написанных на чём угодно. Вполне логично, что во многих случаях первая реализация пишется на скриптовых языках, и только при необходимости переписывается впоследствии на C.
Раз уж пошло обсуждение git. У кого какая практика использования submodules? И использовал ли кто-нибудь subtree? Мы используем submodules, но пришлось прикрутить к нему кучу хуков, чтобы начать более менее удобно ими пользоваться. И всё равно неудобств много. С новыми версиями вводят улучшения по части модулей, но пока коренных изменений не видел никаких.
> С новыми версиями вводят улучшения по части модулей, но пока коренных изменений не видел никаких.Проработайте вопрос и опишите "use cases". Предложите разработчикам на рассмотрение.
Уже. Относительно недавно git проводил опрос с анкетой. В анкете были указаны узкие места, какие смог вспомнить, и способ использования. Не исключено, что именно после опроса начали делать улучшения в модулях, т. к. многие должны были жаловаться. Но возможно, что просто тенденция разработки всё больше склоняется к модулям, т. к. в GitLab CI тоже не так давно (наконец-то!) ввели поддержку модулей при выполнении git fetch.
"Есть у гита такая фича, хотим её использовать" - вот такие в армии мимо гайки и не проходят.
Интересно, что никакого развития, или изменеий, в 'git worktree' не наблюдаю (но я согласен, что я невнимательный).
Я пробовав использовать этот worktree - не прижилось,
хотя git --work-tree= или git --git-dir= использую часто ("спасибо" svn и hg репозиториям).