Опубликован  выпуск распределенной системы управления исходными текстами Git 2.50. Git отличается высокой производительностью  и  предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.  Код Git распространяется под лицензией GPLv2+...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63413

• Выпуск системы управления исходными текстами Git 2.50,бубылдос, 23:41 , 16-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Эксперт, 23:45 , 16-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:56 , 16-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Вася Пупкин, 00:31 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:45 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,12yoexpert, 10:29 , 17-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:49 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 13:09 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:43 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:46 , 16-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:47 , 16-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:54 , 16-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,анон, 05:02 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:46 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:49 , 16-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Вася Пупкин, 00:32 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Самый Лучший Гусь, 23:55 , 16-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Вася Пупкин, 00:30 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:45 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:47 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Соль земли2, 09:48 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 14:08 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 17:31 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:15 , 18-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:02 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:25 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,yet another anonymous, 10:41 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:52 , 17-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,yet another anonymous, 09:41 , 18-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:08 , 18-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,yet another anonymous, 08:51 , 19-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:50 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 11:32 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 11:50 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 12:40 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:47 , 17-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,Аноним, 17:43 , 17-Июн-25
          • Выпуск системы управления исходными текстами Git 2.50,Аноним, 23:05 , 17-Июн-25
          • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:17 , 18-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:11 , 18-Июн-25
          • Выпуск системы управления исходными текстами Git 2.50,Аноним, 08:10 , 19-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:20 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,12yoexpert, 10:59 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:12 , 18-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 08:13 , 19-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:46 , 17-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,Аноним, 00:41 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,penetrator, 01:50 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,adam, 08:43 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 09:41 , 17-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,penetrator, 20:29 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 02:28 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:14 , 18-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 08:16 , 19-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,User, 08:40 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 11:33 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,User, 16:01 , 17-Июн-25
        • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:17 , 18-Июн-25
          • Выпуск системы управления исходными текстами Git 2.50,User, 16:28 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 04:07 , 18-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,Аноним, 01:19 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 06:46 , 17-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,name, 10:07 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:11 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:12 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:48 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,Аноним, 12:17 , 18-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,Аноним, 11:00 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,zionist, 14:07 , 17-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,анонон, 11:35 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 12:53 , 17-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,zionist, 14:06 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 15:01 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,бубылдос, 17:43 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 18:09 , 17-Июн-25
    • Выпуск системы управления исходными текстами Git 2.50,zionist, 19:55 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 20:12 , 17-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:10 , 18-Июн-25
      • Выпуск системы управления исходными текстами Git 2.50,nuclight, 16:20 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Slava, 09:51 , 19-Июн-25
• Выпуск системы управления исходными текстами Git 2.50,Аноним, 19:57 , 17-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Сведущий аноним, 02:15 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 04:10 , 18-Июн-25
  • Выпуск системы управления исходными текстами Git 2.50,Аноним, 10:05 , 18-Июн-25

> Git отличается высокой производительностью

Громкий хохот в зале, местами переходящий в истерику

А что не так-то? Отличается от других высокой производительностью. Стоит сначала другие СКВ поиспользовать, тот же SVN, а потом уже едкие комментарии писать

А вы хоть что-то ещё знаете кроме git и svn, эксперт?

так ты сравнивай одну весовую категорию. централизованную с распределенной ну такое..

> так ты сравнивай одну весовую категорию. централизованную с распределенной ну такое..

И с кем мы будем сравниваться? С Hg чтоли? Он от вгрузки в него чего-то с линухкернел становится убертормозом. Впрочем учитывая что его подкосили питонопроблемы - он уже даже и на ринг то выйти не в форме. И в другом углу ринга у нас ... кто? Зияющая Пустота? Грозный соперник...

например? hg давно сдох, а свн еле трепыхается и только в древних коммерческих проектах

Я не понял, а где стенания и возмущение о вендорлоке? А то wayland^w rust^w systemd^w git монополизировал рынок и уничтожил своих конкурентов.

OK, ну можно сравнить Git и Mercerial.

А почему бы и нет? Централизованные VCS сильно проще, в том числе сильно проще сделать быстрыми, но вот SVN это не мешает тормозить феерически, не говоря даже о всяких перфорсах. Да и среди DVCS никто с гитом по скорости не сравнится.

Наверняка упаковывание зипов с разными версиями быстрее.

С перфорсом сравни, который сабж потеснил.

Боже, я этим дерьмом вынужден был пользоваться 3 года в компании. Как вспомню ажтрясёт. Все эти кривые Helix, SWARM и т.д.

Borland Star Team

> С перфорсом сравни, который сабж потеснил.

Это сабж перфорса не просто потеснил - но и почти аннигилировал. Тот случай когда можно сказать - good riddance!

хз что ты там ржёшь, но да - он быстрый. И уж точно быстрее скриптов на питоне.. всмысле hg, breezy и т.п.

hg почти весь уже переписан. да и аналогов на прочих растах куча

Тем неменее ничего быстрее и лучше не придумали кроме пакования в зип архивы

jujitsu /off

jujitsu это мордочка для git

> Тем неменее ничего быстрее и лучше не придумали кроме пакования в зип архивы

Очень круто работает с линухкернелом - место на диске и правда быстро кончается.

это смех не очень умных людей

Ну хохот не хохот, но у git очень расточительный формат хранилища.
В большинстве случаев одно и то же хранилище, только склонированное занимает в разы больше чем такое же (полная конвертация) у Mercurial. Недавний пример 4G у git и 0.7G у hg.
Дальше при работе только хуже даже с gc.
Это сказывается сетевой передаче при клонировании - да оно объемнее хуже и проблемнее у git (всякого рода докачки и т.д.). А локальные операции надо считать с вместе с косвенными затратами на gc.

Hg хранит инкременты с точность до позиций в строках внутри файлов. Но иногда он делает полный снапшот файла если цепочка заплаток к нему длинная, а сам файл мелкий.

У гита вроде так же, но он наверно он полные снапшоты изменившихся файлов хранит. По другому не понятно откуда берется такая разница в разницу размерах.

> В большинстве случаев одно и то же хранилище, только склонированное
> занимает в разы больше чем такое же (полная конвертация) у Mercurial.
> Недавний пример 4G у git и 0.7G у hg.

Не эквивалентное сравнение. Как насчет git gc --aggressive на этом для именно сравнения возможностей формата? А то мало ли как его при клонировании отгружали на тему сжатия и дельт.

Ну если сравнивать с svn это одно, а если с fossil, это другое. Мне лично fossil нравится, но многие о нем даже не слышали, а там есть кое-что ещё помимо производительности.

> Ну если сравнивать с svn это одно, а если с fossil, это
> другое. Мне лично fossil нравится, но многие о нем даже не
> слышали, а там есть кое-что ещё помимо производительности.

Как фоссил ведёт себя на больших проэктах?

Да он на всех ведёт себя странно: скрещивание VC, wiki и ticket-tracker'а в одном флаконе заходит только проектам из определённых областей и выглядит так себе или совершенно неприемлемо в общем виде.

>скрещивание VC, wiki и ticket-tracker'а в одном флаконе заходит только проектам из определённых областей

Звучит логично. Так как в случае с гитом зеркало репозитория теряет огромное количество информации.

> Так как в случае с гитом зеркало репозитория теряет огромное количество информации.

Это совершенно ложное утверждение. Возможно, вы путаете issue tracker и VC (их путает подавляющее большинство манагеров).

Как мило только что щас было сказано "GitHub не нужен". Смешно, но всё ровно наоборот.

Не смешно. Грустно.

Документация (ну, wiki) --- это про то как этим пользоваться и/или про идею.

Issue tracker --- это про "у клиента при таких-то обстоятельствах всё поломалось" или "нам нужна функциональность X".

VC --- это про "что/зачем я тут наделал/имел в виду, вот в этих строчках", что совсем не про то, как этим пользоваться и не то же самое что исходный issue "#BUG1234 Не открывается страница ....".

Связь между тремя сущностями нетривиальна, и уж точно не "коммит соответствует wiki-странице".

Великий D.E.K. со-товарищи это принесли как literate programming, но ради чего это делали, в целом не получилось. Даже когда это всё в одном файле.

>Мне лично fossil нравится, но многие о нем даже не слышали

Насколько я знаю, там нет rebase. И как там живут?

> rebase

Ненужно. Всё должно храниться в истории. Все ляпы и ужасы.

Новость вроде про распределенную систему контроля версий

Прописываю вам тысячу коммитов за неделю, не меньше. Чтоб знали.

Это делает историю помойкой, отучает коммитить часто. Кроме того, без rebase не будет линейной истории, а ветвящаяся история, опять же, помойка.

>коммитить часто

Никогда не понимал этой привычки. Зачем коммитить недоделаный код? Смысл такой истории, где большая часть коммитов дают несобирающийся проект?

У меня обратная стратегия:

1. Каждый коммит должен собираться и давать работоспособный проект. Каждый.

2. В рамках одной задачи вполне можно обойтись без коммитов. Если будет написан потенциально полезный код, которой позже уйдет из проекта, то не надо надеяться, что его потом удасться выловить из репы, а сразу его оформить в одельный файл-свалку с небольшим комментарием что это такое. Файл с такими недописаными фрагментами только дописыватся и никогда не удаляется.

>Зачем коммитить недоделаный код?

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

Как минимум возможность слить несколько комитов в один - должна быть, как и пересоздать один коммит, на основе другого.
>а сразу его оформить в одельный файл-свалку
>Новая папка, новая папка (2)

Мне кажется, или я это где-то уже видел?

Я вам обоим отвечу - существуют сквош-коммиты (пул-реквесты). Вы можете в своей ветке что угодно делать, её в общем-то можно и удалить в итоге, а потом делать один красивый сквош-комит который отвечает реализации задачи

Это просто у вашего гита архитектура настолько кривая, что не позволяет отображать историю в таких случаях не-помойкой - а именно, в данном случае (там еще кривостей других есть), коммит не знает, к какой ветке он принадлежит. Поэтому он попросту не может сделать (как fossil) эффективный SQL-запрос и показать только нужную ветку, в которую совершенно не важно, сколько там было коммитов в других ветках между мержами.

> он принадлежит. Поэтому он попросту не может сделать (как fossil) эффективный
> SQL-запрос и показать только нужную ветку, в которую совершенно не важно,
> сколько там было коммитов в других ветках между мержами.

Сейчас вот мы еще будем DBA становиться и сиквель запросы писать для контроля версий. Совсем уж BSDшники долбалунилсь.

> Насколько я знаю, там нет rebase. И как там живут?

И вам отвечу это антипаттерн, поэтому там его и нет. Я лично был на проектах где это создало проблемы в git

и не услышат, это поделка-однодневка, завтра закопают

Скоро совершеннолетие отметит "однодневка", на ней работает SQLite, самый популярный и оттестированный продукт в мире (в каждом утюге).

> Скоро совершеннолетие отметит "однодневка", на ней работает SQLite, самый популярный и
> оттестированный продукт в мире (в каждом утюге).

И какой это процент разработчиков чтобы с ними взаимодействовать? А, ну да, rebase там же не нужно. А я им пользуюсь в куче проектов, и ничего, норм.

> Ну если сравнивать с svn это одно, а если с fossil, это другое

Ну да, промышленная VCS и любительская поделка. Но незультат-то один, git победил.

хочу fossil, а должен пользоваться git

хочу OCaml, а вижу javascript (прости, господи)

хочу on-prem, а деньги тают в клауде, как песок сквозь пальцы

хоть SQL и regex родиминький остался

главное логику на уровень базы не выносить ))

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

> Ну да, а то быстро всё начнёт работать

О да, изменение БД на каждый чих - это всегда очень быстро и просто. А потом ещё куча всяких унылых тригеров и хранимок которые регулярно лочат базу, потому что писали их те... кто не смог в нормальный код, а строить из себя незаменимого спеца очень хотелось (ну да, кто ж пойдёт в адеквате этот колхоз чинить за такие смешные деньги)

> И дебажить станет слишком просто

Автотесты для слабаков. Кстати, как там у вас с автотестами? А, никак. И миграции вы тоже никак не трекаете скорее всего, потому что с Code First можно в обе стороны накидать миграцию на раз-два, а люди не умеющие в код про роллбэк даже не задумываются

>[оверквотинг удален]
> и просто. А потом ещё куча всяких унылых тригеров и хранимок
> которые регулярно лочат базу, потому что писали их те... кто не
> смог в нормальный код, а строить из себя незаменимого спеца очень
> хотелось (ну да, кто ж пойдёт в адеквате этот колхоз чинить
> за такие смешные деньги)
>> И дебажить станет слишком просто
> Автотесты для слабаков. Кстати, как там у вас с автотестами? А, никак.
> И миграции вы тоже никак не трекаете скорее всего, потому что
> с Code First можно в обе стороны накидать миграцию на раз-два,
> а люди не умеющие в код про роллбэк даже не задумываются

Code First тоже зло, лучше все-таки моделирование и CASE

В остальном согласен...

И добавлю что логика в базе полностью не поддерживаемое, да и не переносимое.
Тут с ООП сложно качественно, просто и модульно реализовать, а недоязые и подавно.

> хочу fossil, а должен пользоваться git

Он же в sqlite все хранит.

> хоть SQL и regex родиминький остался

А... Ясно

> Он же в sqlite все хранит.

Так это ж хорошо. Нет такого, что во время сбоя по питанию при git pull репа повредилась (реальный случай); найти потомков коммита? легко! и т.д.

> Так это ж хорошо. Нет такого, что во время сбоя по питанию
> при git pull репа повредилась (реальный случай);

Все что надо знать о фрибсдшных "офигенных" файлухах. Но если что - гит это DVCS и вся "трагичность" сводится к тому что в самом пессимистичном случае придется качнуть еще раз.

> найти потомков коммита? легко! и т.д.

Вы как обычно занимаетесь - чем-то не тем. Никто не будет отскребать ошметки репы при крутом факапе. Просто скачают ее заново - и все решение проблем.

> хочу fossil, а должен пользоваться git

Его обычно "хотят" те, кто с ним не работал. Примерно полностью отсутствующая поддержка со стороны современной инфраструктуры разработки ПО делает его использование за пределами сценариев "тихо-сам-с-собою-левою-рукою" или "ну вот мы пилим sqlite патамучта патаму, вот почему!" изрядно утопической.

> современной инфраструктуры разработки

Можете поделиться конкретнее?

>> современной инфраструктуры разработки
> Можете поделиться конкретнее?

Плагин в IDE? Не-а. Нету.
Сколько-нибудь стандартный интерфейс для организации ci\cd pipelines? Тебе надо - ты скрЫпты и пиши.
Публично доступный хостинг? Тоже нет - что в общем-то и не удивительно, т.к. cgi, встроенный web-server и прочие чудо-технологии нагрузку не держат.
Встроенные или сторонние инструменты для code review? Опять нет.
Блин, даже аутентификация\авторизация в каждом репозитории велась независимо друг от друга без каких-либо средств управления этим добром.

> Плагин в IDE? Не-а. Нету.

Зачем? Они и с гитом не нужны.

> Сколько-нибудь стандартный интерфейс для организации ci\cd pipelines? Тебе надо - ты скрЫпты и пиши.

Вопрос к тем хипсторам, которые их пишут. Добавят - будет, нет - ну как будто сильно надо было.

> Публично доступный хостинг? Тоже нет - что в общем-то и не удивительно, т.к. cgi, встроенный web-server и прочие чудо-технологии нагрузку не держат.

chiselapp.com

> Блин, даже аутентификация\авторизация в каждом репозитории велась независимо друг от друга без каких-либо средств управления этим добром.

Щто? Можно подумать в гите подобное своё, а не внешними средствами.

>> Плагин в IDE? Не-а. Нету.
> Зачем? Они и с гитом не нужны.
>> Сколько-нибудь стандартный интерфейс для организации ci\cd pipelines? Тебе надо - ты скрЫпты и пиши.
> Вопрос к тем хипсторам, которые их пишут. Добавят - будет, нет -
> ну как будто сильно надо было.

Ну вот про это и говорю. "Современной инфраструктурой разработки не поддерживается".
А то, что эта самая "современная" всем нужна - никто не говорил, есть куча вещей которая пилится в режиме "для себя и кота" вот вовсе в "новаяпапка062025" и ничо.

>> Публично доступный хостинг? Тоже нет - что в общем-то и не удивительно, т.к. cgi, встроенный web-server и прочие чудо-технологии нагрузку не держат.
> chiselapp.com

Ну ок. Значит уже есть.

>> Блин, даже аутентификация\авторизация в каждом репозитории велась независимо друг от друга без каких-либо средств управления этим добром.
> Щто? Можно подумать в гите подобное своё, а не внешними средствами.

Ну, вот только сам git в голом виде без этих "внешних средств" примерно никому ни ни для чего нафиг не нужен - а тут позиционируется как "готовое решение для". Вот только нифига оно не "готовое"

> хочу fossil, а должен пользоваться git
> хочу OCaml, а вижу javascript (прости, господи)
> хочу on-prem, а деньги тают в клауде, как песок сквозь пальцы
> хоть SQL и regex родиминький остался

Хочу - 180. Могу - 80. Надпись на старом ржавом грузовике.

До сих пор не могут добавить команду удаления подмодуля

git rm <path-to-submodule>

OpenBSDшники уже выкатили got. Git можно (и нужно) выкинуть.

Что за got? В чем преймущество?

> OpenBSDшники уже выкатили got. Git можно (и нужно) выкинуть.

Для тех кто CVS вообще юзал - и got система контроля версий. А остальным обкоцаный экспериенс - зачем?

got это всего лишь мордочка для git.

Никакая это не мордочка, ему не нужен git чтоб работать. Это просто другая система контроля версий, которая использует такой же формат хранения что и git.

Лишь бы на Blake3 не переходить.

NIST не одобрил

> Язык Perl исключён из зависимостей

Наконец-то!

написано же, что "В команде send-email улучшена поддержка SMTP-сервера Outlook.", а это чистый Perl.

> Язык Perl исключён из зависимостей, необходимых для утилит работы с документацией и выполнения тестового набора ("make test"). Многие Perl-однострочники в тестах заменены на функции shell или переписаны на языке Си.

Отлично! Самого ненавидимого языка стало ещё меньше и это радует.

>> Язык Perl
> Отлично! Самого ненавидимого языка стало ещё меньше и это радует.

Прямиком из криокамеры?  
После перла на опеннете стало модно "ненавидеть" (современный сленг: "хейтить") питон, который, еще лет 7 назад успешно сменил Раст
(Rust - современный, относительно низкоуровневый ЯП с аффинными типами, анализатором заимствований и времени жизни, алгебраическими типами данных и прочими современными плюшками из последних 40-50 лет наработок по развитию ЯП) ...

Но это так, цветочки - боюсь, что такие вещи как электрон (современный гуй для десктопа) и JS с CSS в более "классических" (и вымирающих) тулкитах а ля Qt/Gtk вам незайдут еще похлеще перла ...

> питон, который, еще лет 7 назад успешно сменил Раст

Толсто

>> питон, который, еще лет 7 назад успешно сменил Раст
> Толсто

На смену Питону, в качестве (очередного) объекта батхер^W ненависти опеннетовцев, пришел Раст. Так понятнее?

Я вообще не про Опеннет говорил. Перл является самым ненавидимым языком во всём мире.

> Я вообще не про Опеннет говорил. Перл является самым ненавидимым языком во всём мире.

Э-э, Опеннет и есть весь (развитый) айтишный мир.
Лучшие умы, архитекторы и разработчики ПО, ОС и железа тусуются тут и всегда готовы поделиться своей мудростью в комментариях.

А на мнение всяких папуасов с их "почти настоящими самолетами из соломы, палок и коричневой субстанции" - плевать.

Сам опеннет на перле написан.

Чушь какая тролльская.

Возможно лично для вас. В целом довольно хороший язык, и довольно интересный.
Зачем ненавидеть, если можно игнорировать? :)

А SVN жив? Кто-то использует в энтерпрайзе в СНГ?

Жив. Мы используем, хотя собираемся мигрировать на git. Но не в СНГ.

> А SVN жив? Кто-то использует в энтерпрайзе в СНГ?

Примерно как зомби который из могилы порой еше пытается лезть, а его лопатой #%$шат с воплями "тащи осиновые колья!". У меня ЭТО уже не установлено. Никак. Нигде. Так что если вы юзаете это - наше взаимодействие просто не состоится, увы и ах.

Да, жив. Как-то недавно использовал на одном проекте, но проект американский.