The OpenNET Project / Index page

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

Выпуск системы управления исходными текстами Git 2.50

16.06.2025 22:55

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

По сравнению с прошлым выпуском в новую версию принято 621 изменение, подготовленное при участии 98 разработчиков, из которых 35 впервые участвуют в разработке. Основные новшества:

  • Расширена возможность разделения на несколько pack-файлов базы недостижимых объектов ("cruft packs"), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги). Использование нескольких мелких pack-файлов вместо одного крупного позволяет значительно сократить операции ввода/вывода при переупаковке репозиториев с большим числом недостижимых объектов, так как для каждой операции переупаковки не нужно перезаписывать все данные.

    В новой версии предложена опция "--combine-cruft-below-size", при помощи которой можно организовать объединение существующих pack-файлов, размер которых не превышает заданное значение. В отличие от ранее доступной опции "--max-cruft-size" новая опция "--combine-cruft-below-size" не ограничивает максимальный размер результирующего pack-файла, что позволяет более эффективно объединять pack-файлы в репозиториях с большим числом недостижимых объектов, разнесённых по нескольким pack-файлам.

  • Добавлена экспериментальная поддержка инкрементального обновления многопакетных индексов MIDX (multi-pack index), при котором каждый слой MIDX-индекса c информацией о доступности объектов размещается в отдельном bitmap-файле. В очень крупных репозиториях реализованный вид индексов даёт возможность по мере поступления коммитов быстро и эффективно добавлять новые битовые карты доступности объектов.
  • Из кодовой базы удалён старый движок выполнения операций слияния "recursive", на смену которому пришёл полностью переработанный движок "ORT" (Ostensibly Recursive’s Twin), более производительный, функциональный и удобный для сопровождения. ORT позволяет определить возможность объединения двух объектов, не создавая новых объектов в репозитории (при старом движке требовалось выполнение команды "git merge-tree --write-tree", записывающей новые объекты в репозиторий). В Git 2.50 в команде merge-tree реализована опция "--quiet", при которой возможность объединения можно проверить на основе кода возврата без записи данных в репозиторий.
  • В "git cat-file --batch" и подобные команды добавлена опция "--filter", позволяющая пропустить некоторые объекты при выполнении операции.
    
       git cat-file --batch-check='%(objectname)' --filter='object:type=tree' 
    
  • В команде "git maintenance" реализованы три новых действия: worktree-prune, rerere-gc и reflog-expire. Действие worktree-prune предназначено для удаления устаревших или повреждённых рабочих деревьев (worktrees) в репозитории. Действие rerere-gc удаляет старых записи, оставшиеся после устранения конфликтов слияния. Действие reflog-expire удаляет устаревшие недоступные объекты из reflog.
  • Добавлена команда "git reflog drop", удаляющая все данные reflog для указанной ветки.
  • Проведена оптимизация обработки и использования ссылок, например, реализовано кэширование префиксов ссылок, убраны лишние проверки при выполнении команды "git update-ref", повышена эффективность поиска существующих итераторов ссылок.
  • Для библиотеки cURL добавлены настройки KeepAlive: http.keepAliveIdle, http.keepAliveInterval и http.keepAliveCount.
  • В команде "git rev-list" реализована возможность вывода в формате, удобном для машинного разбора, при котором каждое поле разделено символом NUL.
  • Язык Perl исключён из зависимостей, необходимых для утилит работы с документацией и выполнения тестового набора ("make test"). Многие Perl-однострочники в тестах заменены на функции shell или переписаны на языке Си.
  • Добавлен userdiff-обработчик для формата файлов конфигурации ".ini".
  • В команде send-email улучшена поддержка SMTP-сервера Outlook.


  1. Главная ссылка к новости (https://lore.kernel.org/git/xm...)
  2. OpenNews: Выпуск системы управления исходными текстами Git 2.48
  3. OpenNews: Обновление Git с устранением уязвимостей
  4. OpenNews: Доступна децентрализованная система отслеживания ошибок git-bug 0.9
  5. OpenNews: Выпуск git-совместимой системы управления версиями Got 0.100
  6. OpenNews: Пять уязвимостей в Git, среди которых одна критическая и две опасные
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/63413-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, бубылдос (ok), 23:41, 16/06/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –20 +/
     
     
  • 2.2, Эксперт (?), 23:45, 16/06/2025 Скрыто ботом-модератором     [к модератору]
  • +20 +/
     
     
  • 3.8, Аноним (-), 23:56, 16/06/2025 Скрыто ботом-модератором     [к модератору]
  • –7 +/
     
  • 3.12, Вася Пупкин (?), 00:31, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    так ты сравнивай одну весовую категорию. централизованную с распределенной ну такое..
     
     
  • 4.15, Аноним (15), 00:45, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > так ты сравнивай одну весовую категорию. централизованную с распределенной ну такое..

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

     
  • 4.33, 12yoexpert (ok), 10:29, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    например? hg давно сдох, а свн еле трепыхается и только в древних коммерческих проектах
     
     
  • 5.35, Аноним (35), 10:49, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я не понял, а где стенания и возмущение о вендорлоке? А то wayland^w rust^w systemd^w git монополизировал рынок и уничтожил своих конкурентов.
     
  • 4.49, Аноним (49), 13:09, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    OK, ну можно сравнить Git и Mercerial.
     
  • 4.54, Аноним (54), 15:43, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А почему бы и нет? Централизованные VCS сильно проще, в том числе сильно проще сделать быстрыми, но вот SVN это не мешает тормозить феерически, не говоря даже о всяких перфорсах. Да и среди DVCS никто с гитом по скорости не сравнится.
     
  • 2.3, Аноним (3), 23:46, 16/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверняка упаковывание зипов с разными версиями быстрее.
     
  • 2.4, Аноним (4), 23:47, 16/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    С перфорсом сравни, который сабж потеснил.
     
     
  • 3.6, Аноним (6), 23:54, 16/06/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Боже, я этим дерьмом вынужден был пользоваться 3 года в компании. Как вспомню ажтрясёт. Все эти кривые Helix, SWARM и т.д.
     
     
  • 4.21, анон (?), 05:02, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Borland Star Team
     
  • 3.16, Аноним (15), 00:46, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С перфорсом сравни, который сабж потеснил.

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

     
  • 2.5, Аноним (6), 23:49, 16/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    хз что ты там ржёшь, но да - он быстрый. И уж точно быстрее скриптов на питоне.. всмысле hg, breezy и т.п.
     
     
  • 3.13, Вася Пупкин (?), 00:32, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    hg почти весь уже переписан. да и аналогов на прочих растах куча
     
  • 2.7, Самый Лучший Гусь (?), 23:55, 16/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Тем неменее ничего быстрее и лучше не придумали кроме пакования в зип архивы
     
     
  • 3.11, Вася Пупкин (?), 00:30, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    jujitsu /off
     
     
  • 4.55, Аноним (54), 15:45, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    jujitsu это мордочка для git
     
  • 3.17, Аноним (15), 00:47, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Тем неменее ничего быстрее и лучше не придумали кроме пакования в зип архивы

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

     
  • 2.27, Соль земли2 (?), 09:48, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    это смех не очень умных людей
     
  • 2.52, Аноним (52), 14:08, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хохот не хохот, но у git очень расточительный формат хранилища.
    В большинстве случаев одно и то же хранилище, только склонированное занимает в разы больше чем такое же (полная конвертация) у Mercurial. Недавний пример 4G у git и 0.7G у hg.
    Дальше при работе только хуже даже с gc.
    Это сказывается сетевой передаче при клонировании - да оно объемнее хуже и проблемнее у git (всякого рода докачки и т.д.). А локальные операции надо считать с вместе с косвенными затратами на gc.
     
     
  • 3.60, Аноним (-), 17:31, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Hg хранит инкременты с точность до позиций в строках внутри файлов. Но иногда он делает полный снапшот файла если цепочка заплаток к нему длинная, а сам файл мелкий.

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

     
  • 3.77, Аноним (-), 15:15, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > В большинстве случаев одно и то же хранилище, только склонированное
    > занимает в разы больше чем такое же (полная конвертация) у Mercurial.
    > Недавний пример 4G у git и 0.7G у hg.

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

     

  • 1.9, Аноним (-), 00:02, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ну если сравнивать с svn это одно, а если с fossil, это другое. Мне лично fossil нравится, но многие о нем даже не слышали, а там есть кое-что ещё помимо производительности.
     
     
  • 2.10, Аноним (10), 00:25, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну если сравнивать с svn это одно, а если с fossil, это
    > другое. Мне лично fossil нравится, но многие о нем даже не
    > слышали, а там есть кое-что ещё помимо производительности.

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

     
     
  • 3.34, yet another anonymous (?), 10:41, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да он на всех ведёт себя странно: скрещивание VC, wiki и ticket-tracker'а в одном флаконе заходит только проектам из определённых областей и выглядит так себе или совершенно неприемлемо в общем виде.
     
     
  • 4.37, Аноним (35), 10:52, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >скрещивание VC, wiki и ticket-tracker'а в одном флаконе заходит только проектам из определённых областей

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

     
     
  • 5.72, yet another anonymous (?), 09:41, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Так как в случае с гитом зеркало репозитория теряет огромное количество информации.

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

     
  • 4.82, nuclight (??), 16:08, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как мило только что щас было сказано "GitHub не нужен". Смешно, но всё ровно наоборот.
     
     
  • 5.93, yet another anonymous (?), 08:51, 19/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не смешно. Грустно.

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

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

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

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

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

     
  • 2.36, Аноним (35), 10:50, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Мне лично fossil нравится, но многие о нем даже не слышали

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

     
     
  • 3.41, Аноним (41), 11:32, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > rebase

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

     
     
  • 4.45, Аноним (6), 11:50, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Новость вроде про распределенную систему контроля версий
     
  • 4.47, Аноним (35), 12:40, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Прописываю вам тысячу коммитов за неделю, не меньше. Чтоб знали.
     
  • 4.57, Аноним (54), 15:47, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это делает историю помойкой, отучает коммитить часто. Кроме того, без rebase не будет линейной истории, а ветвящаяся история, опять же, помойка.
     
     
  • 5.61, Аноним (-), 17:43, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >коммитить часто

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

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

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

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

     
     
  • 6.67, Аноним (35), 23:05, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Зачем коммитить недоделаный код?

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

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

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

     
  • 6.78, Аноним (-), 15:17, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я вам обоим отвечу - существуют сквош-коммиты (пул-реквесты). Вы можете в своей ветке что угодно делать, её в общем-то можно и удалить в итоге, а потом делать один красивый сквош-комит который отвечает реализации задачи
     
  • 5.83, nuclight (??), 16:11, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто у вашего гита архитектура настолько кривая, что не позволяет отображать историю в таких случаях не-помойкой - а именно, в данном случае (там еще кривостей других есть), коммит не знает, к какой ветке он принадлежит. Поэтому он попросту не может сделать (как fossil) эффективный SQL-запрос и показать только нужную ветку, в которую совершенно не важно, сколько там было коммитов в других ветках между мержами.
     
     
  • 6.90, Аноним (-), 08:10, 19/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > он принадлежит. Поэтому он попросту не может сделать (как fossil) эффективный
    > SQL-запрос и показать только нужную ветку, в которую совершенно не важно,
    > сколько там было коммитов в других ветках между мержами.

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

     
  • 3.79, Аноним (-), 15:20, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Насколько я знаю, там нет rebase. И как там живут?

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

     
  • 2.38, 12yoexpert (ok), 10:59, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    и не услышат, это поделка-однодневка, завтра закопают
     
     
  • 3.84, nuclight (??), 16:12, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Скоро совершеннолетие отметит "однодневка", на ней работает SQLite, самый популярный и оттестированный продукт в мире (в каждом утюге).
     
     
  • 4.91, Аноним (91), 08:13, 19/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Скоро совершеннолетие отметит "однодневка", на ней работает SQLite, самый популярный и
    > оттестированный продукт в мире (в каждом утюге).

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

     
  • 2.56, Аноним (54), 15:46, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну если сравнивать с svn это одно, а если с fossil, это другое

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

     

  • 1.14, Аноним (14), 00:41, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    хочу fossil, а должен пользоваться git

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

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

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

     
     
  • 2.19, penetrator (?), 01:50, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    главное логику на уровень базы не выносить ))
     
     
  • 3.25, adam (?), 08:43, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, а то быстро всё начнёт работать. И дебажить станет слишком просто. И порог вхождения в проект станет слишком низким. Какой здравый человек это всё захочет
     
     
  • 4.26, Аноним (26), 09:41, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну да, а то быстро всё начнёт работать

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

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

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

     
     
  • 5.89, penetrator (?), 20:29, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > и просто. А потом ещё куча всяких унылых тригеров и хранимок
    > которые регулярно лочат базу, потому что писали их те... кто не
    > смог в нормальный код, а строить из себя незаменимого спеца очень
    > хотелось (ну да, кто ж пойдёт в адеквате этот колхоз чинить
    > за такие смешные деньги)
    >> И дебажить станет слишком просто
    > Автотесты для слабаков. Кстати, как там у вас с автотестами? А, никак.
    > И миграции вы тоже никак не трекаете скорее всего, потому что
    > с Code First можно в обе стороны накидать миграцию на раз-два,
    > а люди не умеющие в код про роллбэк даже не задумываются

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

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

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

     
  • 2.20, Аноним (6), 02:28, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > хочу fossil, а должен пользоваться git

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

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

    А... Ясно

     
     
  • 3.85, nuclight (??), 16:14, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Он же в sqlite все хранит.

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

     
     
  • 4.92, Аноним (91), 08:16, 19/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Так это ж хорошо. Нет такого, что во время сбоя по питанию
    > при git pull репа повредилась (реальный случай);

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

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

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

     
  • 2.24, User (??), 08:40, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > хочу fossil, а должен пользоваться git

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

     
     
  • 3.42, Аноним (41), 11:33, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > современной инфраструктуры разработки

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

     
     
  • 4.59, User (??), 16:01, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> современной инфраструктуры разработки
    > Можете поделиться конкретнее?

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

     
     
  • 5.86, nuclight (??), 16:17, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Плагин в IDE? Не-а. Нету.

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

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

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

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

    chiselapp.com

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

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

     
     
  • 6.88, User (??), 16:28, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> Плагин в IDE? Не-а. Нету.
    > Зачем? Они и с гитом не нужны.
    >> Сколько-нибудь стандартный интерфейс для организации ci\cd pipelines? Тебе надо - ты скрЫпты и пиши.
    > Вопрос к тем хипсторам, которые их пишут. Добавят - будет, нет -
    > ну как будто сильно надо было.

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

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

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

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

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

     
  • 2.70, Аноним (70), 04:07, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > хочу fossil, а должен пользоваться git
    > хочу OCaml, а вижу javascript (прости, господи)
    > хочу on-prem, а деньги тают в клауде, как песок сквозь пальцы
    > хоть SQL и regex родиминький остался

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

     

  • 1.18, Аноним (18), 01:19, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    До сих пор не могут добавить команду удаления подмодуля
     
     
  • 2.23, Аноним (23), 06:46, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    git rm <path-to-submodule>
     

  • 1.29, name (??), 10:07, 17/06/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     

  • 1.39, Аноним (39), 11:00, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Лишь бы на Blake3 не переходить.
     
     
  • 2.51, zionist (ok), 14:07, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    NIST не одобрил
     

  • 1.43, анонон (?), 11:35, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Язык Perl исключён из зависимостей

    Наконец-то!

     
     
  • 2.48, Аноним (6), 12:53, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    написано же, что "В команде send-email улучшена поддержка SMTP-сервера Outlook.", а это чистый Perl.
     

  • 1.50, zionist (ok), 14:06, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Язык Perl исключён из зависимостей, необходимых для утилит работы с документацией и выполнения тестового набора ("make test"). Многие Perl-однострочники в тестах заменены на функции shell или переписаны на языке Си.

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

     
     
  • 2.53, Аноним (53), 15:01, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Язык Perl
    > Отлично! Самого ненавидимого языка стало ещё меньше и это радует.

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

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

     
     
  • 3.62, бубылдос (ok), 17:43, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > питон, который, еще лет 7 назад успешно сменил Раст

    Толсто

     
     
  • 4.63, Аноним (53), 18:09, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> питон, который, еще лет 7 назад успешно сменил Раст
    > Толсто

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

     
  • 3.64, zionist (ok), 19:55, 17/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще не про Опеннет говорил. Перл является самым ненавидимым языком во всём мире.
     
     
  • 4.66, Аноним (53), 20:12, 17/06/2025 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 4.74, Аноним (6), 10:10, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сам опеннет на перле написан.
     
  • 4.87, nuclight (??), 16:20, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Чушь какая тролльская.
     
  • 2.94, Slava (??), 09:51, 19/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно лично для вас. В целом довольно хороший язык, и довольно интересный.
    Зачем ненавидеть, если можно игнорировать? :)
     

  • 1.65, Аноним (65), 19:57, 17/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А SVN жив? Кто-то использует в энтерпрайзе в СНГ?
     
     
  • 2.68, Сведущий аноним (?), 02:15, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Жив. Мы используем, хотя собираемся мигрировать на git. Но не в СНГ.
     
  • 2.71, Аноним (70), 04:10, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > А SVN жив? Кто-то использует в энтерпрайзе в СНГ?

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

     
  • 2.73, Аноним (-), 10:05, 18/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, жив. Как-то недавно использовал на одном проекте, но проект американский.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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