Подготовлен (https://public-inbox.org/git/xmqqin3dru2u.fsf@gitster-c.../) выпуск распределенной системы управления исходными текстами Git 2.19.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. По сравнению с прошлым выпуском в новую версию принято 769 изменений, подготовленных при участии 72 разработчиков, из которых 16 впервые приняли своё участие в разработке.
Основные (https://blog.github.com/2018-09-10-highlights-from-git-2-19/) новшества (https://github.com/git/git/blob/v2.19.0/Documentation/RelNot...):- Добавлена команда "git range-diff", позволяющая сравнить разные наборы коммитов. В отличие от "git diff" команда "git range-diff" может охватить более одного коммита и показать не только изменения содержимого и прикреплённых примечаний, но и различия в порядке следования коммитов. Например, новая команда может применяться для оценки различий между состоянием сразу нескольких коммитов после корректировки набора исправлений при помощи "git rebase" в процессе подготовки к слиянию с основным проектом.
На скриншоте ниже показано изменение состояния веток, при котором коммит с добавлением README.md перемещён на первое место, внесено исправление в один из коммитов, исправлено примечание и добавлен дополнительный коммит, вставляющий недостающий символ перевода строки:- В команду "git grep" добавлены новые опции "--column" и "--only-matching" ("-o"). При указании "--column" в выводе кроме номера строки также показывается и номер позиции совпадения в строке. Данную информацию можно использовать в новом дополнении git-jump (https://github.com/git/git/tree/v2.19.0/contrib/git-jump) для Vim, применяемого для точного перехода на искомую позицию в файле при разборе конфликтов слияния, просмотре различий и выполнении операции поиска.
Опция "--only-matching" может применяться для отображения только части строки, подпадающей под заданное регулярное выражение. Например, для подсчёта частоты использования в коде разных вариантов именования хэшей SHA-1 можно использовать команду:- В командах работы с ветками, такими как "git branch", "git tag" и "git for-each-ref", предоставляется опция "--sort", позволяющая определить порядок вывода результатов. В новом выпуске дополнительно предложен параметр "branch.sort", позволяющий определить в файле конфигурации метод сортировки по умолчанию. По умолчанию осуществляется сортировка по имени (refname), но для некоторых разработчиков удобнее метод "authordate", при котором выполняется сортировка по времени последнего обновления (вначале выводятся самые свежие ветки). Также
доступны методы сортировки "numparent" (по числу привязок) и
"upstream" (по серверам, с которых были получены ветки);- Обеспечена автоматическая генерация списка автодополнения ввода для большинства команд и опций файла конфигурации;
- В функциях создания и верификации цифровых подписей для коммитов и тегов появилась поддержка применения утилиты gpgsm (https://www.gnupg.org/documentation/manuals/gnupg/Invoking-G...), которая используется сертификаты X.509 вместо ключей OpenPGP;
- Опция "-l" в "git branch", которая является сокращением опции "--create-reflog", объявлена устаревшей и теперь приводит к выводу предупреждения. В будущем планируется сделать "-l" сокращением опции "--list", по аналогии с командой "git tag -l";- Добавлена настройка checkout.defaultRemote, позволяющая определить удалённый сервер, используемый по умолчанию для выполнения операции checkout с именем внешней ветки, в случае если данная ветка присутствует одновременно на нескольких серверах;
- При помощи атрибута working-tree-encoding теперь можно задать желаемую кодировку текста в привязке к отдельным файлам, что позволяет решить проблемы с обработкой UTF-16 как бинарных данных. При установке атрибута данные будут хранится в UTF-8, но при операции checkout отдаваться в желаемой кодировке, т.е. корректно будут работать такие команды, как "git diff";
- Добавлена (https://github.com/git/git/blob/master/Documentation/technic...) экспериментальная возможность частичного клонирования репозиториев, позволяющая организовать работу не имея полной копии всего репозитория и без всей истории изменений. Например, при работе с небольшой частью очень большого репозитория частичное клонирование позволит при операциях clone и fetch ограничиться загрузкой только среза необходимых данных, без блобов и лишних веток. В дальнейшем, при обращении к отсутствующим объектам, данные объекты будут на лету загружаться с сервера по мере необходимости. Большинство внешних серверов пока не поддерживают частичное клонирование, но для локальных экспериментов можно использовать команду "git clone --filter=blob:none";
- Представлена экспериментальная возможность хранения объектов в форме графа коммитов (https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar.../), при котором для индексации используется не линейный список хэшей объектов со ссылками на другие объекты, а древовидная структура в виде графа. Если сейчас для определения релизов в которых содержится определённое исправление требуется загрузка каждого объекта с диска для поиска ссылок, то при хранении в виде графа можно сразу определить все необходимые связи. Для включения нового метода хранения можно использовать команду "git config core.commitGraph true". Тестирование нового метода хранения с репозиториями ядра Linux, Git и Windows показало почти двухкратное увеличение производительности операций с ветками:Команда До После Изменение
Linux:
git merge-base master topic 0.52 0.06 -88%
git branch --contains 76.20 0.04 -99%
git tag --contains 5.30 0.03 -99%
git tag --merged 6.30 1.50 -76%
git log --graph -10 5.90 0.74 -87%Git:
git merge-base master topic 0.10 0.04 -60%
git branch --contains 0.76 0.03 -96%
git tag --contains 0.70 0.03 -96%
git tag --merged 0.74 0.12 -84%
git log --graph -10 0.44 0.05 -89%Windows:
git status --ahead-behind 14.30 4.70 -67%
git merge-base A B 11.40 1.80 -84%
git branch --contains 9.40 1.60 -83%
git log --graph -10 24.30 5.30 -78%- Кроме того, продолжается развитие ранее начатых экспериментальных проектов: уход от применения скомпрометированного (https://www.opennet.me/opennews/art.shtml?num=46232) алгоритма SHA-1 для хэширования объектов (ожидается опциональная поддержка SHA3-256, которая сможет применяться параллельно с SHA-1) и переход на вторую версию (https://www.opennet.me/opennews/art.shtml?num=48622) коммуникационного протокола Git (примечателен возможностью фильтрации веток и тегов на стороне сервера и средствами для расширения протокола).
URL: https://blog.github.com/2018-09-10-highlights-from-git-2-19/
Новость: https://www.opennet.me/opennews/art.shtml?num=49254
Полезное дело делают. Респект и уважуха!
Тут самое небольшое увеличение производительности -67%. Это "почти двукратное"? Иногда вообще -99%.
Вот такое двукратное стократное увеличение :)
Проценты в школе ещё не проходили? Двухкратное ускорение это прирост ускорения в 100%.
> Проценты в школе ещё не проходили? Двухкратное ускорение это прирост ускорения в
> 100%.А ещё, я слыхала, в шоле проходят отрицательные числа.
#>>> Изменение: -99%
Но это неточно.
> Тестирование нового метода хранения с репозиториями ядра Linux, Git и Windows показало почти двухкратное увеличение производительности операций с веткамиЧто значит почти двухкратное? Почти двухкратное - это меньше, чем -50%. -99% (как для git branch --contains в Linux) - это уже более чем в 100 раз.
гуманитарии, сэр!
что за шрифт у чувака на скриншотах?
Ты хотел спросить, что за лютое ШГ там?
Fira Mono вроде
Ошибся, это Fira Code - https://github.com/tonsky/FiraCode
спасибо
можно ли использовать гит для бекапов бинарных файлов?Ищу способ делать бекапы файлов с возможностью отката (на случай если что то пошло не так и хеши отличаются от старых) - либо читал задницей, либо rsync в это не может искаропки (велосипед на питоне, создающий поддиректории с сегодняшней датой при различии хешей не очень быстро работает)
> либо читал задницейИменно. --link-dest=DIR
примеры в студию - емнип сабж для другого совсем
Для больших файлов отдельно git LFS запилили. Насколько вам подойдет - не знаю.
https://git-lfs.github.com/
Можно. Но есть специальные программы для беккапирования. Например, http://duplicity.nongnu.org
bup, borgbackup
Можно но каждая версия будет весить столько же как и оригинал, т.к. дифф оно умеет делать только для текста.
> ... но каждая версия будет весить столько же как и оригинал, т.к. дифф оно умеет делать только для текста.Это ложное утверждение. Для делты это почти так, но хранятся не
только дельты. Если blob'ы "похожи", то прирост объёма может оказаться
минимальным. "Похожесть" не базируется на строчном представлении
(т.е. текстом быть не обязана).
>> ... но каждая версия будет весить столько же как и оригинал, т.к. дифф оно умеет делать только для текста.
> Это ложное утверждение. Для делты это почти так, но хранятся не
> только дельты. Если blob'ы "похожи", то прирост объёма может оказаться
> минимальным. "Похожесть" не базируется на строчном представлении
> (т.е. текстом быть не обязана).Хм, действительно. Спасибо!
http://git.661346.n2.nabble.com/diff-ing-files-td6446460.htm...
<= https://stackoverflow.com/questions/9478023/is-the-git-binar...
посмотри в сторону syncthing, если конечно бекапить нужно на удаленную систему
Э... Так оно синхронизирует. И стёр "здесь" - стёрлось и "там". Если конечно не делать Read-only
Оно умеет какой-то контроль версий, но я его не осилил.
> Добавлена экспериментальная возможность частичного клонирования репозиториевУра.
> Тестирование нового метода хранения с репозиториями ядра Linux, Git и WindowsЯдро Windows стало опенсорсным?
> Ядро Windows стало опенсорсным?Нет. MS перешла на git, как основную VCS.
>> Тестирование нового метода хранения с репозиториями ядра Linux, Git и Windows
> Ядро Windows стало опенсорсным?Не... микросовт перешёл на гит. "н-хаузе". Теперь _все_ патчи гита -- чтоб воно на уинде нитормозило.
:/
> Ядро Windows стало опенсорсным?Нет, но TFS оказался полным калом, настолько что даже сам MS был вынужден это признать. Следующим логичным шагом будет дропнуть к чертям ядро windows, потому что оно линуху по перфомансу все больше продувает.
Интересно а можно ли использовать Гит не только для кода, а например, для контроля версий мультимедийных исходников?
Например распределённая запись музыки и звука, децентрализованного создания мультфильмов.
> Интересно а можно ли использовать Гит не только для кода, а например,
> для контроля версий мультимедийных исходников?
> Например распределённая запись музыки и звука, децентрализованного создания мультфильмов.Автомобиль форд может быть любого цвета, если этот цвер чёрный. => ...можно использовать, если управлять тектовыми исходниками.
Для этого есть git-annex. Очень крутая штука.
Гит не очень хорошо дружит с блобами:Вы не сможете корректно мёржить бинарные данные в случае конфликтов в ветках.
Репозиторий будет расти очень быстро. Тупить будет всё сильнее. Смотрите в сторону
https://git-lfs.github.com/
Бред. "merge" может иметь очень разные стратегии. А упоминать такую
гадость как git lfs ...
Не смогу распарсить самую первую ссылку новастиhttps://public-inbox.org/git/xmqqin3dru2u.fsf@gitster-c.../
Я Щитаю это бан.
обоснуй
http...@...фишинг
Ьан тут разве что за незнание синтаксиса URL, чтоли.
> Не смогу распарсить
> Я Щитаю это бан.Ну-ну, не надо к себе так строго. Просто немного подрасти.
Скорее бы ушли от использования SHA1!
Куда?
к текущему стандарту sha3