The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск распределенной системы управления исходными текстами Git 2.13.0

10.05.2017 09:32

Доступен выпуск распределенной системы управления исходными текстами Git 2.13.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, LibreOffice, Systemd, X.Org, Wayland, Mesa, GStreamer, Wine, Debian, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP, Python, Xen, Minix.

По сравнению с прошлым выпуском в новую версию принято 729 изменения, подготовленных при участии 65 разработчиков, из которых 15 впервые приняли своё участие в разработке. Основные изменения:

  • Устранена уязвимость (CVE-2017-8386), которая позволяет запустить внешние команды при подсоединении к репозиторию через SSH в режиме "git-shell" (оболочка, ограничивающая ssh-клиентов только операциями с git). В частности, при выполнении "git upload-pack --help" запускается интерактивный интерфейс для постраничного просмотра подсказки, из которого можно вызвать произвольные программы на стороне удалённой системы. Конфигурации, использующие git-shell вместе с gitolite проблеме не подвержены;
  • Добавлен код для выявления в Git-репозиториях известных коллизий в хэшах SHA-1, который поможет защититься от возможных атак через подмену репозитория. В дальнейшем планируется избавиться от жёсткой привязки Git от SHA-1 и добавить опциональную поддержку SHA3-256, которая сможет применяться параллельно с SHA-1. Таким образом, переведённый на SHA3-256 локальный репозиторий сможет взаимодействовать с Git-серверами (как минимум на уровне push/fetch), поддерживающими только SHA-1, а пользователи смогут одновременно использовать идентификаторы объектов SHA-1 и SHA3-256;
  • Расширены возможности по использованию шаблонов файловых путей в командах 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".


  1. Главная ссылка к новости (http://lkml.iu.edu/hypermail/l...)
  2. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.12.0
  3. OpenNews: GitHub добавил защиту от атак, использующих коллизии SHA-1
  4. OpenNews: Компания Microsoft представила виртуальную файловую систему для Git
  5. OpenNews: Первый выпуск Gitea, форка системы совместной разработки Gogs
  6. OpenNews: Релиз распределенной системы управления исходными текстами Git 2.11.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46523-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:20, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    А чем разрабов git не устраивает ~/.config/git по дефолту? Все вечно стремятся нагадить в корневую своими конфигурационными файлами
     
     
  • 2.2, Crazy Alex (ok), 11:30, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тем, что всем нужны разные конфигурации. Ваш К.О.

    .git/config не клонируется, само дерево - клонируется. То есть в .git/config ложатся приватные настройки репозитория, в дерево - то, что должно быть у всех

     
     
  • 3.7, Какаянахренразница (ok), 11:46, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Тем, что всем нужны разные конфигурации. Ваш К.О.
    > .git/config не клонируется, само дерево - клонируется. То есть в .git/config ложатся
    > приватные настройки репозитория, в дерево - то, что должно быть у
    > всех

    Я пытался уловить связь твоего ответа с заданным вопросом. И не уловил.

     
     
  • 4.9, Crazy Alex (ok), 12:39, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сорри. Спать мне надо больше, совсем торможу сегодня.

    Перепутал .config/git с .git/config

     
  • 2.5, Какаянахренразница (ok), 11:38, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А в каком стандарте написано, что именно там находится дефолт?
     
     
  • 3.8, sokoloff (??), 12:03, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > А в каком стандарте написано, что именно там находится дефолт?

    В XDG Base Directory Specification https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

     
     
  • 4.11, Аноним (-), 12:49, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, там действительно так написано. Только вот непонятно мне, почему консольная утилита git должна следовать стандарту для десктопных окружений?
     
     
  • 5.15, Аноним (-), 13:40, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Только вот непонятно мне, почему теплая утилита
    > git должна следовать стандарту для мягких окружений?

    fix.
    https://www.freedesktop.org/wiki/Software/

     
  • 5.16, Crazy Alex (ok), 13:50, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что это разумно? Я понимаю, если бы таких стандартов был пяток, и в гите бы выбрали не тот, что кому-то нравится. Но зачем хомяк забивать?
     
  • 5.17, sokoloff (??), 13:56, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да, там действительно так написано. Только вот непонятно мне, почему консольная утилита
    > git должна следовать стандарту для десктопных окружений?

    А почему бы и нет? Если вместо кучи дот-файлов в хомяке будет несколько поддиректорий, IMHO будет только лучше. Да и бэкапить удобнее.

     
     
  • 6.28, Аноним (-), 18:25, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Да и бэкапить удобнее.

    Конечно. Вместо одного .git бэкапить тройку .config/git, .cache/git, .local/share/git. Красота!

     
     
  • 7.30, Аноним84701 (ok), 18:33, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Конечно. Вместо одного .git бэкапить тройку .config/git, .cache/git, .local/share/git.
    > Красота!
    >  .cache/git,

    На кой бэкапить кэш-то? 0_o

     
  • 7.36, Crazy Alex (ok), 21:56, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем? .config, .local бэкапятся целиком, .cache так же целиком игнорится.

    Ну, или исключения для некоторых пишутся, но один хрен большинство уходит в бэкап.

     
  • 5.43, Аноним (-), 10:44, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >почему консольная утилита git должна следовать стандарту для десктопных окружений?

    Чтобы в хомяке сам чёрт ногу не сломал.

     
  • 3.10, Аноним (-), 12:41, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В стандарте от freedesktop:
    https://www.freedesktop.org/wiki/Specifications/basedir-spec/
     
  • 2.13, Алексей (??), 13:21, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Уже пять лет как устраивает https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.12.txt#L18

     

  • 1.3, X3asd (ok), 11:30, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > часто, после ввода "{" разработчики допускали опечатку и вводили первый символ с большой буквы

    но зачем они это делали?

    и почему именно первый символ?

    где логика?

     
     
  • 2.4, Crazy Alex (ok), 11:33, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В том, что { вводится с зажатым Shift, часто не успеваешь отпустить
     
  • 2.14, Алексей (??), 13:24, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что в последовательности @{u} три символа и четырёх набираются с шифтом. И я рад, что теперь мне теперь будет проще зажать его и набрать все четыре символа @{U}
     
     
  • 3.23, Аноним (-), 15:34, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никогда этого не понимал. Всегда, любой текст в любых скобках набираю вот так, и проблем не знаю: открывающая скобка→закрывающая скобка→курсор между ними→текст в скобках. В случае с @{u} три символа подряд набираются с зажатым шифтом, потом шифт безболезненно отпускается
     
     
  • 4.29, Аноним (-), 18:30, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не всем нравиться стоя в гамаке.
     
     
  • 5.31, Аноним (-), 18:44, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не всем нравиться стоя в гамаке.

    А, совершенно внезапно, еще есть раскладки, в которых шифт для этого вообще не требуется.

    Хотя конечно прикольно - с одной стороны такие вот как вы, любят повозмущаться "они не в курсе, что есть не только ASCII|лат.буквы, но и другие кодировки|графемы|нужное вставить!", с другой стороны, даже не желают задумываться о том, что их раскладка далеко не единственная в мире )

     

  • 1.6, gaga (ok), 11:43, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Забавно, что столько коммитов в этот ваш гит, а он все так же ощущается как куча костылей^Wскриптов-на-перле-и-баше, склеенных друг с другом изолентой.
     
     
  • 2.12, Аноним (-), 13:05, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Другое дело hg на пистоне... зато не на перле.
     
     
  • 3.20, Аноним (-), 14:35, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не всем дана способность управлять столь большим количеством степеней свободы который дает perl.
    "Всех неосиляторов в биореакт\^W питон." (с)
     
  • 3.39, Вареник (?), 10:46, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да уж получше. Целостность меркуриала против заплаточности гит.
     
  • 2.18, leap42 (ok), 14:10, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    знали бы вы, сколько "костыли на перле" жизней спасли)
     
     
  • 3.33, A.Stahl (ok), 19:21, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А сколько погубили?
     
     
  • 4.42, Котофалк (?), 18:53, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А скольким пофиг?
     
  • 2.19, Аноним (-), 14:31, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Любой проект написанный "для себя", "под определенную задачу" или просто "для себя" всегда выглядит как набор костылей когда "вырастает из своих штанишек". То что вы не понимаете этого говорит о вас что вы либо админ локалхоста, либо хеллоуворлдщик.
     
     
  • 3.21, gaga (ok), 15:11, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Я это понимаю, и, собственно, этот факт констатировал в своем комментарии. Мне просто грустно, что при наличии грамотно реализованных инструментов (hg и другие) все всё равно пользуются этим "выросшим из штанишек" просто потому что "так заведено".
     
     
  • 4.24, Аноним (-), 16:23, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дело не в том что "так заведено", а потому что пользовать git - это круто, а hg - уныло.
     
     
  • 5.27, Блондинка. (?), 17:11, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Минусуют - значит не понимают. Тогда я уточню.
    Все идет от инструментов. Вот hg - уныло потому что сам python - это уныло, и это перекинулось на hg.

    Если python2 было что-то вроде "пиитоон", то есть медленно и неповоротливо, то python3 - это уже "пииитооон", то есть еще медленней и неповоротливей. Поэтому python - синоним слова "уныло" и "бесперспективно".

    Хаскель, например, это круто. Си - это круто. Perl - это круто. Erlang, lisp, asm, oberon - это все тоже круто!! PHP - помойка. Java - это не круто и не прикольно, но серьезно.
    А python - это уныло и самое важное - бесперспективно (фатальный недостаток).

     
  • 4.34, АнонимХ (ok), 19:51, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только вендузятники любят за черепашку, больше ничего в нем хорошего нет. Работаешь с ним всегда, будто бегаешь в болотных сапогах.
     
     
  • 5.40, Вареник (?), 10:47, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только
    > вендузятники любят за черепашку, больше ничего в нем хорошего нет. Работаешь
    > с ним всегда, будто бегаешь в болотных сапогах.

    Именно что лучше спроектирован, продуман. В отличии от зоопарка заплаток.

     
     
  • 6.41, Andrey Mitrofanov (?), 15:01, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Hg - грамотно реализованный? Может еще скажете, что грамотно спроектированный? Его только
    > Именно что лучше спроектирован, продуман. В отличии от зоопарка заплаток.

    Да, проектирование на питонах https://glandium.org/blog/?p=3835 это главное.

     
  • 3.25, Аноним (-), 16:46, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Причём тут какие-то штанишки? Вполне нормальный юниксвейный подход: основной функционал на C, вспомогательные инструменты, весь смысл которых в последовательном запуске бинарей с разными опциями, на шелле.
     
     
  • 4.26, Аноним (-), 16:55, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    При том что речь была про архитектуру, а не ее реализацию. Еще даже не хеллоуворлдщик?
     
     
  • 5.32, Аноним (-), 19:16, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и я про архитектуру, джун. Это называется расширяемость: новый функционал легко добавляется с помощью скриптов/бинарей, написанных на чём угодно. Вполне логично, что во многих случаях первая реализация пишется на скриптовых языках, и только при необходимости переписывается впоследствии на C.
     

  • 1.35, Аноним (-), 21:02, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Раз уж пошло обсуждение git. У кого какая практика использования submodules? И использовал ли кто-нибудь subtree? Мы используем submodules, но пришлось прикрутить к нему кучу хуков, чтобы начать более менее удобно ими пользоваться. И всё равно неудобств много. С новыми версиями вводят улучшения по части модулей, но пока коренных изменений не видел никаких.
     
     
  • 2.37, Аноним (-), 22:51, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > С новыми версиями вводят улучшения по части модулей, но пока коренных изменений не видел никаких.

    Проработайте вопрос и опишите "use cases". Предложите разработчикам на рассмотрение.

     
     
  • 3.38, Аноним (-), 07:34, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Уже. Относительно недавно git проводил опрос с анкетой. В анкете были указаны узкие места, какие смог вспомнить, и способ использования. Не исключено, что именно после опроса начали делать улучшения в модулях, т. к. многие должны были жаловаться. Но возможно, что просто тенденция разработки всё больше склоняется к модулям, т. к. в GitLab CI тоже не так давно (наконец-то!) ввели поддержку модулей при выполнении git fetch.
     
  • 2.45, Аноним (-), 09:51, 18/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    "Есть у гита такая фича, хотим её использовать" - вот такие в армии мимо гайки и не проходят.
     

  • 1.44, Аноним (-), 21:50, 16/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, что никакого развития, или изменеий, в 'git worktree' не наблюдаю (но я согласен, что я невнимательный).
    Я пробовав использовать этот worktree - не прижилось,
    хотя git --work-tree= или git --git-dir= использую часто ("спасибо" svn и hg репозиториям).
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру