Увидел свет (https://lkml.org/lkml/2016/6/13/880) выпуск распределенной системы управления исходными текстами Git 2.9.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/).
По сравнению с прошлым выпуском в новую версию принято 497 изменения, подготовленных при участии 75 разработчиков, из которых 28 впервые приняли своё участие в разработке. Основные (https://github.com/git/git/blob/v2.9.0/Documentation/RelNote...) изменения (https://github.com/blog/2188-git-2-9-has-been-released):
- В дополнение к появившейся в прошлом выпуске возможности извлекать субмодули (репозитории, включённые в состав другого репозитория) в несколько параллельных потоков (например, "git fetch --recurse-submodules --jobs=4") в новой версии добавлена возможность использования опции "--jobs" для распараллеливания операций клонирования и обновления субмодулей:
git clone --recurse-submodules --jobs=4 ...
git submodule update --jobs=4 ...
Распараллеливание процесса обработки субмодулей также можно включить через установку директивы submodule.fetchJobs в файле конфигурации.- Добавлены новые возможности для управления поведением клонировния и извлечения субмодулей. Git теперь отражает опции командной строки в командах субмодулей. Например, для одноразовой установки переменной для всех извлечённых субмодулей можно запустить "git -c http.proxy=... clone --recursive";
- Добавлена возможность использования при выполнении "git clone" опции "--shallow-submodules", которая позволяет значительно сократить время клонирования репозиториев с субмодулями;
- В "git diff" добавлена экспериментальная опция "--compaction-heuristic" (diff.compactionHeuristic в файле конфигурации), включающая
дополнительную эвристику для корректного отображения логики изменений, в которых фигурируют повторяющиеся блоки. Например, если раньше изменения определялись по первому совпадению:values.each do |v|
+ v.prepare
+ end
+
+ values.each do |v|
v.finalize
end
end
то теперь, на основании наличия пустой строки-разделителя более точно отражается принадлежность изменённых элементов:def finalize(values)
+ values.each do |v|
+ v.prepare
+ end
+
values.each do |v|
v.finalize
end
Кроме того, добавлена настройка interactive.diffFilter, упрощающая установку альтернативных обработчиков вывода различий в "git add -i".
Добавлен новый скрипт-фильтр diff-highlight (https://github.com/git/git/tree/master/contrib/diff-highlight), выделяющий цветом различия сегментов кода. Для установки фильтра можно использовать команду "git config interactive.diffFilter diff-highlight";module Foo
def output
- puts "hello, world!"
+ puts "goodbye, world!"
end
end
- Команда "git rebase -x" теперь может применяться для тестирования всех коммитов без включения интерактивного режима. В новой версии, если не указать флаг "-i" операция "git rebase -x" будет применена для всех коммитов и завершит выполнение на первом проблемном коммите с выводом сообщения об ошибке. После исправления проблемы предлагается продолжить проверку, запустив команду "git rebase --continue". Подобный подход удобен для быстрой проверки всей серии коммитов в проектах, в которых не принято рецензирование каждого изменения. Например, для тестирования полной ветки можно выполнить:$ git rebase -x 'make test'
Executing: make test
Result: OK
Executing: make test
Result: FAIL
make: *** [test] Error 2
Execution failed: make test
You can fix the problem, and then run
git rebase --continue
исправляем ошибку и продолжаем проверку$ make test
Result: OK$ git commit -a --amend
$ git rebase --continue
Executing: make test
Result: OK
Successfully rebased and updated refs/heads/your-branch.- Изменён метод поиска тегов по читаемым именам коммитов, выдаваемых командой "git describe". Если раньше при выборе имени в режиме "--contains" использовался ближайший тег, что могло привести к нелогичным результатам при наличии более новых тегов, содержащих коммит, то в новой версии применён более простой для понимания хронологический порядок - используется самый старый тег, содержащий коммит;
- В "git log" обеспечено раскрытие символа табуляции с учётом применяемого при выводе 4-символьного выравнивания, что позволяет корректно отобразить ASCII-рисунки в коммитах;
$ git log
commit 8d7fca1d690ff2ffb678dc00fbca1954df5e5b90
Author: Mu-An Chiou
Date: Mon Sep 23 09:21:03 2013 +0900_____
╲ ╲
│ │
│ │ ___________________________
└─#──┘ ######## / |
## ##~ ~ ~ ## / |
##### ##########
- Включён по умолчанию режим определения переименования файлов при анализе различий в "git diff" и
"git log". Git не сохраняет информации о переименованиях, но может определять их налету на основе оценки различий между новыми и старыми файлами. Данная возможность присуттвует с первых дней существования git, но только теперь включена по умолчанию;- Возможность определения собственных путей для скриптов-обработчиков событий (хуков). Если ранее скрипты могли находиться только в директории .git в каждом репозитории, то сечас можно определить единый для всех репозиториев набор типовых скриптов, находящихся в любой части ФС. Для задания пути следует использовать настройку core.hooksPath;
- В утилите git-p4 (импорт и экспорт в Perforce) появилась поддержка сопоставления пользователей p4 и идентификаторов Git, а также записи информации о работах p4 в текст примечаний к коммитам.
- В состав включён скрипт git-multimail 1.3.1 (https://github.com/git-multimail/git-multimail) для рассылки уведомлений о выполнении операций push;
- Для защиты от слияний по ошибке при выполнении "git merge" запрещено по умолчанию слияние двух веток, не имеющих общего предка;URL: https://lkml.org/lkml/2016/6/13/880
Новость: https://www.opennet.ru/opennews/art.shtml?num=44600
> В "git diff" добавлена экспериментальная опция "--compaction-heuristic" (diff.compactionHeuristic в файле конфигурации), включающая дополнительную эвристику для корректного отображения логики изменений, в которых фигурируют повторяющиеся блокиЛучший релиз-2016
> git clone --recurse-submodules --jobs=4 ...
> git submodule update --jobs=4 ...Это так нужно?
Вот произвести операцию на одним субмодулем - да. А сделать просто - никак. Только хитро:
git submodule foreach --recursive 'if [ $name = "SUBMODULE_IN_QUESTION" ]; then DO_THINGS; fi'
Когда проект большой, и сабмодулей там штук сорок - то очень даже нужно. Особенно в каком-нибудь CI, где гит дёргается на каждый чих, часто - несколько раз в минуту.
Ясно. Git оптимизируют для роботов, а людям упражняться в набивании букв. Хотя мне казалось, что обновление субмодулей - это очень активное random I/O, которое и так очень медленное. Сомневаюсь, что эти CI работают на SSD, т.к. постоянная вот такая писанина их бы слишком быстро изнашивала. Короче, нужен какой-нибудь репозиторий с кучем сабмодулей, чтобы оценить преимущества. Хотя, похоже, догадался. Эти субмодули просто сравнительно редко обновляются, т.е. практически всегда нужно только быстро получить подтверждение, что ничего не поменялось. ОК, согласен.
> Git оптимизируют для роботов, а людям упражняться в набивании буквДля людей всегда был Mercurial.
Кстати, Python project к осени мигрирует на GitHub.
> Для людей всегда был Mercurial.С каких это пор приматов приравняли к людям?
Там, где я видел подобное, оно, скорее всего, постоянно в кэше ФС лежит - памяти в достатке. Ну и да, обновляются они на порядки реже, чем основная репа.А насчёт оптимизаций... Добавляется то, что кому-то нужно и что кому-то было не лень написать. Поучаствуйте если необходимость есть, делов-то.
люто плюсую
>You are downloading the latest (2.8.4)и где вышла?
git clone https://github.com/git/git
Нужно больше гита!
git clone git@github.com/git/git.git
git clone git://github.com/git/git.git
> В "git log" обеспечено раскрытие символа табуляции с учётом применяемого при выводе 4-символьного выравнивания, что позволяет корректно отобразить ASCII-рисунки в коммитах;ждем поддержку емоджи и анимированных gif'ок
дурацкий сарказм получился. гифки от гита вообще не зависят все вопросы к терминалу, эмодзи можете хоть сейчас использовать.
Вообще-то ASCII-графика, иллюстрирующая какую-нибудь структуру - не ахти какая редкость.
> HUBOTмне кажется или та гифка факью тычет ?
> Вообще-то ASCII-графика, иллюстрирующая какую-нибудь структуру - не ахти какая редкость.возможно, но зачем оно в сообщении к коммиту?! Можно привести какой нибудь реальный пример, где бы ascii схема была реально полезна и востребованна в коммите? Мне на ум что то не приходит таких юзкейсов
> Можно привести какой нибудь реальный пример, где бы ascii схема была реально полезна и востребованна в коммите?Например, можно показать структуру, в которую данные сериализуются: сколько байт заголовок стартовой последовательности, где начинается полезная нагрузка, где стоповая последовательность.
Но зачем всё это в комментарии к коммиту?
Ты из тех, кто пишет коммиты: "many fixes"?
Нет, но и пихать в сообщение к коммиту спецификацию формата/протокола -- тоже крайность.
> пример, где бы ascii схема была реально полезна и востребованна в коммите
>юзкейсовWhat?
>>юзкейсов
> What?use cases
> гифка факью тычет ?Нет, ю!
> Возможность определения собственных путей для скриптов-обработчиков событий (хуков).Нужно попробовать запушить что-нибудь по этим путям (попробовать переписать хуки).
> Например, можно показать структуру, в которую данные сериализуются: сколько байт заголовок стартовой последовательности, где начинается полезная нагрузка, где стоповая последовательность.и зачем это пихать в коммит? В чем глубокий смысл? Типа все такие гики и сидят в консолях?
Зачем сразу гики, просто нерукожопые люди и профессионалы сидят в териманах.
> Теперь, на основании наличия пустой строки-разделителя более точно отражается принадлежность изменённых элементов.
> Если ранее скрипты могли находиться только в директории .git в каждом репозитории, то сечас можно определить единый для всех репозиториев набор типовых скриптов, находящихся в любой части ФС.Джва года ждал такие фичи!
> Добавлен новый скрипт-фильтр diff-highlight, выделяющий цветом различия сегментов кода.
И это тоже отнюдь не лишнее.
> Включён по умолчанию режим определения переименования файлов при анализе различий в "git diff" и "git log".
Очень давно пора.
>> Включён по умолчанию режим определения переименования файлов при анализе различий в "git diff" и "git log".
> Очень давно пора.$ git config --global diff.renames true