Представлен (https://lkml.org/lkml/2015/9/28/777) релиз распределенной системы управления исходными текстами Git 2.6.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/), Xen (http://xenbits.xen.org/gitweb/), Minix (http://git.minix3.org/).
По сравнению с прошлым выпуском в новую версию принято 479 изменений, подготовленные при участии 67 разработчиков, из которых 15 впервые приняли своё участие в разработке. Основные изменения:
- Реализации "git pull" и "git am" переписаны на языке Си;- Выполнена подготовка к реализации поддержки подключения различных бэкендов с реализации ссылочных хранилищ, предлагающих альтернативный способ хранения, не ограниченный традиционным подходом "один ref на один файл или упаковкой в файл packed-refs". Проведена чистка refs API;
- Добавлена возможность сброса входящих пакетов в файл для последующей отладки;
- Внесена порция улучшений, связанных с возможностями "git am" по чтению патчей от других систем контроля версий;- Возможность использования символа звёздочки для определения маски файлового пути в обоих частях refspec (например, "refs/heads/o*:refs/remotes/heads/i*");
- В userdiff добавлено определение шаблона для формата разметки Fountain (http://fountain.io/);
- В "git log" и похожие команды добавлена опция "--date=format:..." для форматирования времени при помощи вызова strftime;
- В "git rebase -i" добавлена команда "drop commit-object-name subject", как альтернативный способ избежать повторного коммита;
- Добавлена новая конфигурационная переменная для автоматического использования опции "--follow" при запуске "git log" с одним аргументом спецификации файлового пути;- В "git status" обеспечен вывод детальной информации о выполняемом в текущий момент сеансе "rebase -i";
- В "git cat-file" добавлена опция "--batch-all-objects" для перебора всех доступных в репозитории объектов. Новый режим работает быстрее, чем выполнение "rev-list --all --objects" и не включает в вывод недоступные объекты;
- Команда "git fsck" теперь игнорирует ошибки, связанные с объектами, помеченными как повреждённые, и допускает тонкую настройку уровня предупреждений для различных видов некритичных проблем;
- Возможность настройки списка задач (todo) для "git rebase -i";- Введена переменная окружения GIT_REPLACE_REF_BASE, через которую можно указать альтернативный путь к иерархии ссылок с данными замены объектов, вместо использования штатного пути "refs/replace/";
- Обновлены размещённые в директории contrib скрипты автодополнения ввода командной строки;
- В команду "git send-email" добавлена опция "--smtp-auth" для задания списка допустимых механизмов аутентификации SMTP ("SMTP AUTH");
- Добавлена новая переменная конфигурации http.sslVersion, позволяющая ограничить версии SSL/TLS, которые допустимо использовать при установке соединения;- Добавлена переменная конфигурации notes.mergeStrategy, которая аналогична опции "--strategy=how", задающей метод автоматической обработки конфликтов в "git notes merge";
- Для "git config --list" представлена опция "--name-only", при указании которой вывод формируется в виде, удобном для автоматического разбора скриптами (значения не разбиваются на отдельные строки);
- Проведена работа по увеличению удобства работы в интерфейсе gitk.
URL: https://lkml.org/lkml/2015/9/28/777
Новость: http://www.opennet.me/opennews/art.shtml?num=43057
> Реализации "git pull" и "git am" переписаны на языке Си;а на чем было? О_О
было на баше. у гита есть низкоуровневая база данных объектов, есть низкоуровневые операции вроде $ git-ls-tree b2efb2a7e48025c4d185080412a6ba1121ee6c59для общего развития настоятельно рекомендую: http://www.opennet.me/base/dev/git_guts.txt.html
> было на баше.На #!/bin/sh, да. https://github.com/git/git/blob/master/contrib/examples/git-...
Мда, из крайности в крайность...
> Мда, из крайности в крайность...Гугле-лето-студенты выискивают "конфетки в... Windows же":
a promising 8x improvement in execution time on Windows.
[...]
`git-pull` and `git-am` are frequently used git subcommands.
However, they are porcelain commands and implemented as shell
scripts, which has some limitations which can cause poor
performance, especially in non-POSIX environments like Windows.http://git.661346.n2.nabble.com/RFC-GSoC-Proposal-Make-git-p...
А как оно у меня работает при отсутствии этого вашего басша?
Там sh а не баш. Просто выросло поколение неучей которые из не различают. Это ещё ладно, а ведь иногда их допускают до писания скриптов, и тогда несовместимое ни с чем bash-онлу гoвнo начинает дрызгать рекой.
Как будто это что-то плохое...
О ученый выискался, а ну как как рекомендовано писать $() или `` ?
Неужели трудно набрать
man bash, man ksh, man sh, man <ваш_любимый_шелл>?
поддерживаю, чем плохо написание скриптом на баше, а не сш?
Тем, что у того, кто будет пользоваться, не обязательно будет bash, у которого есть свои специфические особенности ("bash-измы"). А синтаксис Bourne shell (он же sh) стандарт да-факто и поддерживается в *.nix везде и всем.
Или для вас сюрприз, что шеллы ограничиваются не только bash-ем и их в общем-то хватает разных?
Не помню линукса, где не было бы баша по дефолту. А если БСДМшники страдают - это by design.
> поддерживаю, чем плохо написание скриптом на баше, а не сш?Друзья проприертарщиков страдают же. И виноваты в этом те, кто пишет на #!/bin/bash-е.
Очевидно же!
Git написан на смеси сишечки, шелла и перла.
// Комментарий специально для противников Mercurial.
> а на чем было? О_Оgit am - на шеле и перле. Без последнего - не работал
> Проведена работа по увеличению удобства работы в интерфейсе gitkQGIT умер окончательно? :(
gitk - наше всё
gitk + git-gui - самые удобные клиенты (не считая Emacs)
А ничего, что команда "git gui" может запускать разные софтины? :)
И чем это плохо? для разрешения мерж-конфликтов meld очень удобен. А что кроме него она запускает? И чем это плохо?По-моему, это хорошо, когда велосипед не изобретается, а берётся и катается. Вы со мною не согласны?
tig наше все!
Git прекрасен, но действительно конфеткой его делают 2 программы для Windows:
- окно истории коммитов (Log Messages) в TortoiseGit
- и из того же набора TortoiseGitMerge
Что ты делаешь с Git в Windows?
> Что ты делаешь с Git в Windows?Он же написал, ищет конфетки в... Windows же.
Попробуйте Git Extensions: он такой же красивый и понятный, но в отличие от TortoiseGit, не пытается сделать вид, что Вы работаете с Subversion.И даже умеет добавлять в индекс патчи кусками (почти уровень штатной `git gui`).
> патчи кусками"git add -p"?
Да, именно это.Правда, когда я смотрел на него задний раз, он не умел добавлять выбранные строки из куска (как `git gui`), а возможности *редактировать* куски перед добавлением по-моему нет вообще ни в одном GUI фронт-енде.
Но хоть что-то...
Они бы лучше git status ускорили а то на реально больших проектах тормозит. Можно иногда минуту ждать пока прочухает. Основное время конечно сканирование файловой системы у него занимает, но может что-то и можно ускорить там.
> Они бы лучше git status ускорили а то на реальноЗамучили https://github.com/msysgit/git/pull/94 уже сосвоим Майкрософтом. Мы-то за что страдаем?!
> больших проектах тормозит. Можно иногда минуту ждать пока прочухает. Основное время конечно сканирование
круто если так, я как раз года два ничего настолько большого и не смотрел
> Они бы лучше git status ускорили а то на реально больших проектах
> тормозит. Можно иногда минуту ждать пока прочухает. Основное время конечно сканирование
> файловой системы у него занимает, но может что-то и можно ускорить
> там.Ничего там нельзя ускорить, как ни крути нужно обойти всё поддерево ФС и проверить не изменилось/добавилось ли что. Есть -u no, но не заметил чтобы оно что-то заметно ускоряло, хотя и не замерял. Со стороны git тут ничего не сделать, поэтому это вопрос уже к файловой системе. Я проблему решил (у меня ZFS) добавив SSD для L2ARC. ZFS в этом плане очень рулит, потому что не нужно никуда руками переносить данные или думать куда монтировать диск - подключил, после первого git status репозиторий свалился в кэш, второй статус и далее обрабатываются мгновенно потому что читают с ssd. 128G мне лично хватает, после месяца работы используется только 70G кэша.
>> Они бы лучше git status ускорили
> Ничего там нельзя ускорить, как ни крути нужно обойти всё поддерево ФС- при записи время модификации каталогов разве не распространяется вверх по дереву ?
> Они бы лучше git status ускорили а то на реально больших проектах
> тормозит.Посмотрите на 2.x.x <https://github.com/git-for-windows/git/releases> (собственно, 1.9.x уже не развивается; разве что критичные баги там будут правиться): в ней реализовано экспериментальное кэширование информации о файлах, которое ускоряет `git status`.
git 2.6.0 на win 8.1 по-прежнему безбожно тормозит с `git status`. с включенным кэшированием, ага.
> git 2.6.0 на win 8.1 по-прежнему безбожно тормозитВсё правильно - так и должно быть.
не распределённая, а децентрализованная.распределённая, - это когда так: gitchain.org
>не распределённая, а децентрализованная.тьфу ты, наоборот
Ещё не совсем проснулся? :)
Много изменений в сравнении с прошлым релизом, где не было ничего интересного. Это радует.