The OpenNET Project / Index page

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



"Выпуск распределенной системы управления исходными текстами ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от opennews (?), 08-Июн-19, 14:46 
Представлен (https://lkml.org/lkml/2019/6/7/117) выпуск распределенной системы управления исходными текстами Git 2.22.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.


По сравнению с прошлым выпуском в новую версию принято  745 изменений, подготовленных при участии  74 разработчиков, из которых 18 впервые приняли участие в разработке. Основные (https://github.blog/2019-06-07-highlights-from-git-2-22/)  новшества (https://github.com/git/git/blob/master/Documentation/RelNote...):

-  Доступный начиная с выпуска 1.18 новый режим переноса набора коммитов "git rebase --rebase-merges" заменил собой старую опцию  "--preserve-merges", которая теперь помечена как устаревшая. Операция "git rebase" применяется для замены серии коммитов на новый базовый коммит, например, для сдвига отдельной ветки, в которой развивается какая-то новая возможность, к актуальному состоянию master-ветки, включающей исправления, добавленные после ответвления:


                o --- o --- o (my-feature)

              /

o --- o --- o --- o --- o (master)


                            o --- o --- o (my-feature)

                          /

o --- o --- o --- o --- o (master)


Для сохранения структуры ветвления в переносимой ветке ранее могла применяться опция "--preserve-merges", которая при запуске в интерактивном режиме (git rebase -i --preserve-merges) позволяла редактировать историю коммитов, но не гарантировала полное сохранение структуры репозитория. Пришедший на смену режим "--rebase-merges" позволяет сохранить структуру изменений в переносимой ветке, предоставляя при этом полный набор интерактивных операций, включая удаление, перегруппировку и переименование коммитов.


Например, "--rebase-merges" позволяет (https://i2.wp.com/user-images.githubusercontent.com/443245/5...) перезалить коммиты из отдельной ветки на более новую master-ветку, сохранив при этом структуру ветвления в переносимой ветке, и внести на ходу некоторые изменения в примечания к коммитам.


-  Добавлена поддержка создания новой ветки на основе результата определения базы слияния двух других веток (merge base, привязка к общему предку) при помощи конструкций "git branch new A...B" и "git checkout -b new A...B", в которых "A...B" подразумевает определение базы слияния между двумя указанными коммитами, по аналогии с тем, как "git checkout A...B" смещает HEAD на базовый коммит и "diff A...B" показывает изменения между коммитом "B" и общим с коммитом "А" предком.


Например, при  работе над отдельной веткой my-feature предложенную возможность можно использовать когда требуется начать с другой ветки, например,  с того же места в master-ветке, с которого была извлечена ветка my-feature. Ранее для этого требовалось вручную изучить лог изменений, что создавало неудобство при наличии большой истории изменений, затем выполнить "git merge-base master my-feature" для вычисления хэша базы слияний между ветками master и my-feature и создать новую ветку относительно общего предка "git branch my-other-feature хэш". В Git 2.22 для создания ветки относительно базы слияния двух других веток можно использовать синтаксис "git branch my-other-feature A...B";


-  Добавлена опция "git branch --show-current" для отображения имени ветки, полученной при выполнении операции checkout;

-  Добавлена опция "git checkout --no-overlay -- dir", позволяющая при выполнении операции checkout привести содержимое каталога dir к виду, полностью соответствующему состоянию master-ветки. Например, если в локальной копии каталога dir имеется файл, отсутствующий в master-ветке, то по умолчанию при выполнении "git checkout master -- dir" он будет оставлен, а при указании опции "--no-overlay" удалён;

-  В команде "git diff" задействован универсальный API для разбора опций, что позволило унифицировать обработку опций с другими утилитами git. Например, в "git diff" для всех опций теперь  доступны и их антагонисты ("--function-context" и "--no-function-context");

-  Добавлена возможность фильтрации при выводе "git log" прикреплённых к коммитам расширенных меток ("trailer" - дополнительные информационные флаги, такие как Signed-off-by и Co-authored-by). Возможна фильтрация меток как по ключу, так и по значению, например:
"git log --pretty="%(trailers:key=Reviewed-by,valueonly)";

-   Добавлен новый механизм трассировки Trace2, предлагающий более гибкий и структурированный формат вывода. Trace2 позволяет собирать телеметрию о выполняемых операциях и данных о производительности для более детального анализа и отладки (обработчик назначается пользователем, никакие данные не отправляются вовне);


-  Сделан более читаемым отчёт "git bisect", в котором теперь более наглядно выделяются проблемные коммиты и выводятся сводная статистика по изменениям для каждого файла (на уровне числа изменённых строк);

-  Переработана эвристика определения переименований  каталогов с целью исключения ложной установки меток переименования. При наличии сомнений подобные каталоги теперь помечаются конфликтующими;


-  Обеспечен вывод предупреждения при попытки установки тега на другой тег, что, как правило, совершается по ошибке и может привести к установке метки не на тот коммит (например, конструкция вида "git tag -f -m "updated message" my-tag1 my-tag2" приведёт к созданию тега на старый тег, в то время как разработчик рассчитывал, что новый тег будет установлен на коммит, на который указывает старый тег);

-  Включена генерация для репозиториев битовых карт (дисковая структура "reachability bitmaps"), сохраняющих данные о наборах объектов, доступных для каждого коммита, и позволяющих быстро определить наличие базового объекта. Указанная структура заметно сокращает время выполнения операций извлечения данных (git fetch).

URL: https://github.blog/2019-06-07-highlights-from-git-2-22/
Новость: https://www.opennet.ru/opennews/art.shtml?num=50831

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск распределенной системы управления исходными текстами ..."  –5 +/
Сообщение от segesg (?), 08-Июн-19, 14:46 
Народ, какой максимальный размер репы git с которой вам приходилось работать?
У меня на 10Gb начинал притормаживать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск распределенной системы управления исходными текстами ..."  +3 +/
Сообщение от Аноним (2), 08-Июн-19, 15:01 
Просто для информации: по опыту, на винде работает на порядки медленнее, чем на линуксе. Возможно, проблема может быть в этом.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Выпуск распределенной системы управления исходными текстами ..."  +3 +/
Сообщение от Иваныч (??), 08-Июн-19, 16:46 
Там где есть много внешних вызовов падение производительности весьма заметное. Я недавно заменил tr, который использовался для проведения всего в нижний регистр, на встроенную команду от bash и прирост был около 2-х раз. Тоже касается команд для определения имени и деректории, в итоге скорость sh скрипта стала сопоставима с Linux окружением. С 15-ти минут к 20 секундам, в соотношении с 15 секундам на Linux.  
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Выпуск распределенной системы управления исходными текстами ..."  +2 +/
Сообщение от Додо (?), 08-Июн-19, 20:49 
А на кой вам 10 гигабайт хранить в репозитории?
Если он увеличился до подобных размеров - наверное, есть смысл разбить на несколько отдельных репозиториев?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "Выпуск распределенной системы управления исходными текстами ..."  +2 +/
Сообщение от Аноним (6), 08-Июн-19, 23:36 
Не знаю как у топик стартера, но я видел уникомов, которые хранили с vcs результаты компиляции (объектники, exe-шники и пр.). Для небольших проектов размеры репы доходили до 300-500 мегабайт.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

19. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от Аноним (19), 09-Июн-19, 21:39 
А сожалению есть популярные репозитории, хранящие всю многогиговую историю. По-моему, единственное, что тут нужно сделать - это заморозить кодовую базу в смысле "не принимаем новые фичи в этот репозиторий", отребейзить все неслитые ветки, включая PR, на macter, пофиксить, перезаписывая историю, после чего cкопировать рабочую копию в новую папку и создать новый репозиторий. Старый переименовать в old-0, в initial commite  дат ссылку на него. Пересоздать все ветки. Должно сильно уменьшить объём.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

23. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (23), 10-Июн-19, 02:10 
Если нужно отделить "старую" историю от "текущей" истории,
то можно воспользоваться способом из книги Pro Git (https://git-scm.com/book/en/v2).
Способ описан в главе о команде Replace.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

25. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (25), 10-Июн-19, 19:07 
Зачем терять историю? Пускай себе лежит. Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

26. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от Аноним (26), 11-Июн-19, 12:09 
>Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное

Это всё рано стянет ненужное, если хоть маленький кусочек старья по-прежнему используется.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (27), 15-Июн-19, 14:40 
Стянет ровно столько, сколько попросишь, не больше и не меньше. Иди читай, как git работает.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

5. "Выпуск распределенной системы управления исходными текстами ..."  +3 +/
Сообщение от Линус (?), 08-Июн-19, 20:57 
.gitignore в помощь
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от segesg (?), 08-Июн-19, 23:42 
Минусующие такие минусующие)
Мусора в репе нет, про ингнор в курсе
С Windows не работал уже лет 10 наверное
Делить по ряду причин неудобно, там другие проблемы вылазят
Видимо тут никто с реально большими репами не работал, ну да ладно
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

8. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от KonstantinB (ok), 09-Июн-19, 00:22 
Да понятно что будет тормозить.

Надо делить на модули/пакеты - либо стандартными для используемого стека средствами, либо, на худой конец, через сабмодули. Да, для легаси это тяжело и болезненно, но никуда не денешься, придется рано или поздно.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Crazy Alex (ok), 09-Июн-19, 00:27 
Ну порядка гига репа совершенно нормально себя чувствует... правда, на ssd. С бОльшими не работал.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

13. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от без имени (?), 09-Июн-19, 12:24 
скорее всего ключевое слово здесь SSD - аналогично 12 гигов репа (размер .git директории) работает нормально на SSD, на харде эта же репа заметно притормаживает на больших операциях
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (27), 09-Июн-19, 08:17 
Не понял — репа 10Г или отдельно взятый срез 10Г? Если второе, ты явно что-то делаешь не так. Если первое — не припоминаю, чтобы с таким сталкивался, но в пределах 1-2Г тормозов не наблюдал (хотя в тех случаях тоже многое делалось не так).
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Выпуск распределенной системы управления исходными текстами ..."  +2 +/
Сообщение от .anonymous (?), 09-Июн-19, 11:01 
Под "репой" имеется в виду ".git" или содержимое репозитория на последнем commit-е? Если первое, и если я правильно помню (но могу ошибаться), то гигов 100. Работало нормально.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

20. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от segesg (?), 09-Июн-19, 22:54 
Во, это уже тема!
Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.
Можно поинтересоваться сколько примерно в вашей репе объектов, сколько времени длится коммит и rebase, и сколько клиентов тянет сервер?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

24. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (27), 10-Июн-19, 08:35 
> Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.

Соотношение-то какое? Если у тебя там огромные объекты, git будет тормозить, потому что он так устроен, а ты используешь его не по назначению. Если просто очень много объектов в истории, особых тормозов быть не должно.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

15. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 09-Июн-19, 17:19 
Около 40GiB, залитая в Git svn-помойка. И, конечно же, на таких объёмах он хорошо не работает.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 09-Июн-19, 17:30 
Ну и скорость работы в большей степени зависит от кол-ва объектов репозитории и в индексе
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

12. "Выпуск распределенной системы управления исходными текстами ..."  +1 +/
Сообщение от Аноним (12), 09-Июн-19, 12:19 
Git LFS https://git-lfs.github.com/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Выпуск распределенной системы управления исходными текстами ..."  –2 +/
Сообщение от Аноним (19), 09-Июн-19, 21:32 
Не взлетел, ибо костыль.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

21. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (27), 10-Июн-19, 00:24 
Однако ж получше других костылей типа fedpkg.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

14. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (14), 09-Июн-19, 13:25 
Годнота, спасибо!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (19), 09-Июн-19, 21:32 
Когда уже на sha256 перейдут?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Выпуск распределенной системы управления исходными текстами ..."  +1 +/
Сообщение от Аноним (27), 10-Июн-19, 00:25 
> Добавлена опциональная возможность применения алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при сборке Git в режиме "NewHash". Код для обхода дерева объектов изменён с учётом того, что имена объектов могут вычисляться не только с использованием SHA-1.

https://www.opennet.ru/opennews/art.shtml?num=50202

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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