The OpenNET Project / Index page

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

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

21.04.2026 12:01 (MSK)

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

По сравнению с прошлым выпуском в новую версию принято 770 изменений, подготовленных при участии 137 разработчиков (66 впервые приняли участие в разработке Git). Основные новшества:

  • Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений, более простые и безопасные в использовании, чем перебазирование коммитов командой "git rebase". Предоставляются две операции:
    • "git history reword <commit>" для перезаписи сообщения в указанном коммите без изменения рабочего дерева и индекса (кроме примечания, остальное остаётся нетронутым). Например, для исправления опечатки.
    • "git history split <commit>" для интерактивного разделения указанного коммита на два разных коммита с перемещением выбранных частей из исходного коммита в дополнительный коммит.

    В будущих выпусках ожидается добавление дополнительных команд: "git history fixup" для исправления коммита, "git history drop" для удаления коммита, "git history reorder" для изменения порядка следования коммитов и "git history squash" для объединения коммитов.

  • Реализован новый метод определения обработчиков (hook) в файлах конфигурации. Вместо размещения скриптов с обработчиками в каталоге ".git/hooks" в каждом репозитории, команды для вызова обработчиков теперь можно задавать непосредственно в файлах конфигурации. Настройки можно привязывать к репозиторию или указывать в файлах конфигурации, действующих для всех репозиториев (/etc/gitconfig) или репозиториев пользователя (~/.gitconfig). Возможна привязка нескольких обработчиков к одному событию. Скрипты из ".git/hooks" по-прежнему продолжают вызываться, но запускаются после обработчиков из файлов кофигурации. Для просмотра списка обработчиков следует использовать команду "git hook list", а для выборочного отключения вызова обработчиков - настройку "hook.<name>.enabled = false".
    
       [hook "linter"]
          event = pre-commit
          command = ~/bin/linter --cpp20 
    
       [hook "no-leaks"]
          event = pre-commit
          command = ~/bin/leak-detector
    
       $ git hook list pre-commit
       global    linter  ~/bin/linter --cpp20
        local    no-leaks    ~/bin/leak-detector 
    
    
  • В команде "git maintenance" по умолчанию задействована стратегия "geometric" ("git config set maintenance.strategy geometric"), позволяющая сократить время обслуживания крупных монорепозиториев. По сравнению с ранее применяемой стратегией, использующей логику как в команде "git gc", новая стратегия избегает переупаковки всех объектов и исключает излишне ресурсоёмкие операции, такие как слияние всех pack-файлов (по возможности объединение производится частями и без чистки удалённых объектов).
  • База данных объектов (ODB) и связанные с ней API переведены на новую архитектуру, основанную на использовании подключаемых бэкендов. Проведённая реструктуризация абстрагирует формат хранения объектов и в дальнейшем позволит реализовать такие возможности, как альтернативные бэкенды и форматы объектов, например, для более эффективного хранения крупных бинарных файлов или для оптимизации работы крупных git-хостингов.
  • В команде "git repo structure", выводящей сведения о структуре репозитория, обеспечено отображение не только общего размера, но и показа самых крупных объектов каждого типа, что позволяет обойтись при оценке размера без использования сторонней утилиты git-sizer.
    
       $ git repo structure
       ...
       | * Largest objects         |             |
       |   * Commits               |             |
       |     * Maximum size    [1] |   17.23 KiB |
       |     * Maximum parents [2] |      10     |
       |   * Trees                 |             |
       |     * Maximum size    [3] |   58.85 KiB |
       |     * Maximum entries [4] |    1.18 k   |
       |   * Blobs                 |             |
       |     * Maximum size    [5] | 1019.51 KiB |
       |   * Tags                  |             |
       |     * Maximum size    [6] |    7.13 KiB |
    
  • В команде "git replay", применяемой вместо "git rebase" для воссоздания истории на сервере без рабочего дерева, включено по умолчанию атомарное обновление ссылок (вместо вывода списка команд update-ref для ручного выполнения), реализована опция "--revert" для отмены изменений от серии коммитов, обеспечено отбрасывание результирующих пустых коммитов и появилась возможность воссоздания истории вплоть до корневого коммита.
  • В "git rev-list" и похожие команды добавлена опция "--maximal-only" для показа только коммитов, недостижимых другими коммитами.
  • В команду "git repo info" добавлена опция "--keys" для вывода списка всех известных ключей.
  • В команде "git add -p" при навигации между блоками кода при помощи клавиш "J" и "K" обеспечена пометка уже одобренных и пропущенных блоков. Добавлена опция "--no-auto-advance" для отключения автоматического перехода к следующему файлу, чтобы иметь возможность вернуться к прошлым файлам перед коммитом.
  • Проведена оптимизация web-интерфейса "gitweb" для работы с мобильных устройств.
  • В команде "git apply --directory" перед использованием обеспечена нормализация файловых путей, таких как "./un/../normalized/path".
  • Документирована возможность добавления собственных подкоманд через размещение файлов "git-<cmd>" в каталоге с исполняемыми файлами.
  • В команду "git send-email" добавлена поддержка клиентских сертификатов.
  • Для команды "git status" реализована настройка "status.compareBranches", через которую можно указать ветки, с которыми будет производиться сравнение текущей ветки.
    
    [status]
       compareBranches = @{upstream} @{push}
    
  • В "git rebase" добавлена опция "--trailer" для упрощения добавления метаданных ко всем коммитам.
    
       git rebase --trailer "Reviewed-by: Test <test@example.com>"
    
  • В команду "git fast-import" добавлена возможность замены подписей для коммитов, которые стали невалидны после импорта.
  • Добавлена поддержка упаковки (compaction) многопакетных индексов MIDX (multi-pack index), при которой между собой объединяются мелкие слои MIDX-индекса c информацией о доступности объектов и связанные с ними bitmap-файлы, что позволяет уменьшить число накопившихся слоёв в давно существующих репозиториях.
  • В команде "git backfill" реализована возможность указания ревизий (диапазонов коммитов) и масок путей (pathspec) для ограничения загружаемых частей истории изменений.
    
       git backfill main~100..main
       git backfill -- '*.c'
    
  • Добавлены альтернативные формы вызова команды "git config list" - "git config -l" и "git config --list".
  • Разрешено использование не-ASCII символов в именах псевдонимов команд, задаваемых в файле конфигурации.
    
       [alias "получить"]
           command = fetch
    
  • Изменено отображение подписей, у которых истёк срок действия GPG-ключей, но которые были валидны на момент подписания коммита. Подобные подписи теперь отображаются как корректные с примечанием об устаревании ключа (ранее они подсвечивались красным цветом, что создавало впечатление об их некорректности).
  • При обращении к репозиториям по HTTP обеспечена обработка ошибки с кодом 429 (Too Many Requests). Завершившиеся подобной ошибкой запросы теперь рассматриваются не как фатальная проблема, а как временная ошибка, для которой через какое-время следует повторить операцию. Задержка перед повтором задаётся через опцию "http.retryAfter", число повторов - "http.maxRetries", время ожидания - "http.maxRetryTime".


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


Обсуждение (121) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:31, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Лучшая система контроля версий ever.
     
     
  • 2.2, Аноним (2), 12:33, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –4 +/
    cvs лучше
     
     
  • 3.3, Аноним (3), 12:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, рар
     
  • 3.27, Аноним (27), 14:38, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +7 +/
    src_yyyy.mm.dd.zip же!
     
     
  • 4.97, OpenEcho (?), 23:52, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Cmon... 'restic backup', удобней :)
     
  • 2.4, Аркагоблин (?), 12:41, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно подумать есть выбор. GitHub, GitLab, даже Codeberg - всё заточено на Git. Да, можно найти маргинальный сервис с чем-то другим, но если у кода не появится пользователей (а там их точно не появится!), то зачем тогда публиковать?
     
     
  • 3.21, Аноним (21), 14:11, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не понял смысл твоего мутного высера. Лично где ты был когда игнорировали Mercurial?
     
     
  • 4.86, ыыыыы (?), 20:52, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ушёл с меркуриала - ни о чём не жалею
     
     
  • 5.109, Вася Пупкин (?), 13:12, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    вытолкнули с hg, жалею и скучаю. приходиться жрать гит
     
  • 3.38, Аноним (38), 15:23, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для альтернативно одарённых есть новодельные vcs совместимые с гитовым хранилищем, например jj. Попробуйте, расскажете.
     
  • 3.41, Аноним (41), 15:28, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >GitLab, даже Codeberg - всё заточено на Git

    Нужен либо аналог, либо поддержка в одном из.
    >то зачем тогда публиковать?

    Поднимайте зеркало, и публикуйте и там и там, в чём проблема?

     
     
  • 4.48, Аркагоблин (?), 16:10, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем мне публиковать и там и там? Только ради другой СКВ, чтобы показать "что у меня не git"? Нет, спасибо
     
     
  • 5.81, Аноним (41), 19:18, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем вам вообще нужна альтернатива гиту?
     
     
  • 6.83, Аркагоблин (?), 19:22, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Лично мне не за чем
     
     
  • 7.85, Аноним (38), 20:09, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда к чему вообще был разговор про отсутствие выбора?
     
     
  • 8.93, Аркагоблин (?), 22:04, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что вы сравниваете лучший и не лучший словно кроме Git есть реальные ... текст свёрнут, показать
     
     
  • 9.128, Аноним (38), 18:39, 22/04/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 3.56, Аноним (-), 17:01, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну так был sourceforge, тормозил с гитом по упора, сватая отличные CVS и SVN -... большой текст свёрнут, показать
     
     
  • 4.77, Аноним (77), 18:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >SVN

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

     
     
  • 5.105, Аноним (-), 12:31, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не
    > знаешь, в какую репу коммитишь.

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

    И тут гит такой за несколько секунд мне запрошенную версию linux kernel - хренась, раскатывает как из пушки! Ну что, "система контроля версий" версии то надо было контролировать - вот как-то так.

     
  • 5.127, Аноним (38), 18:36, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну субмодули, справедливости ради, именно для этого и были сделаны - прозрачно коммитить в другую репу, и в git они работают так же.
     
  • 3.98, OpenEcho (?), 23:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подумать есть выбор.

    Ну вон sqlite вполне себе обходится fossil-scm, который по ходу all-in-one и трекер и форум и вики и SCM и всё в одном флаконе, а с "миром" (с гитом т.е.)  через импорт/экспорт

     
     
  • 4.111, Аноним (38), 15:16, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    sqlite обходится этой noдeлкoй потому что это noдeлкa того же автора (причём чсх контрибушоны он не принимает, т.е. флоу совместной разработки через fossil вообще не использует и даже не представляет насколько он ужасен). Больше никто её не использует.

    > а с "миром" (с гитом т.е.)  через импорт/экспорт

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

     
     
  • 5.131, Прохожий (??), 02:33, 23/04/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.5, Аноним (5), 12:43, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Лучшая система контроля версий ever.

    Нету конкурентов. BitKeeper послал ядро и Линуса, ядро и Линус послало биткипера, так появился гит.

     
     
  • 3.24, Аноним (24), 14:25, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Юникс послал гну и ядро и так появился Линукс.
     
     
  • 4.57, Аноним (-), 17:02, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >  Юникс послал гну и ядро и так появился Линукс.

    Наоборот. Но суть в целом не меняет.

     
  • 3.29, Аноним (38), 14:44, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ой, конкурентов навалом было - инвалидный hg, маргинальные фоссилы и пихули, математичный darcs ажно основанный на patch theory. История рассудила.
     
  • 2.20, IMBird (ok), 14:09, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ... называется hg.
     
     
  • 3.58, Аноним (-), 17:13, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ... называется hg.

    Месиво на питоне который нетормозит (так что каждую версию рассказывали на сколько именно неторможение улучшено). И который отлично совместим между версиями. Но правда к моменту дропа версии 2 - коса нашла на камень и столько кода переписать до потери актуальности господа просто не смогли нормально.

     
     
  • 4.110, Вася Пупкин (?), 13:13, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    что с ним надо делать, чтоб он тормозил?
     
     
  • 5.112, Аноним (38), 15:16, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Написать что-то сложнее hello, world.
     
  • 5.118, Аноним (-), 17:19, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > что с ним надо делать, чтоб он тормозил?

    Поворочать им проект чуть крупнее чем я и мой хелловорлд. Линух кернел в него загони с всеми ревизиями и посмотри как тебе ЭТО будет. А гиту нормально, фигли.

     
  • 2.44, Аноним (-), 15:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Dacrs/Pijul?
     
  • 2.78, ptr (ok), 18:51, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря для чего. Если именно для текстов - да. Если же есть необходимость в системе контроля версий  для бинарных данных, то нет. C этим SVN справляется намного лучше.
     
     
  • 3.84, Аноним (38), 19:44, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > C этим SVN справляется намного лучше.

    И в чём лучшесть? Гиту, на самом деле, вообще по барабану какие данные трекать - с блобами он справляется также как с текстом, с большими блобами так же как с маленькими.

    Когда говорят о бинарных данных, обычно имеют в виду что не хотят хранить всю их историю локально. Для этого есть LFS, другой инструмент тащить совершенно не обязательно. Тем более SVN, который "лучше" не справляется вообще ни с чем.

     
     
  • 4.96, ptr (ok), 23:24, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> C этим SVN справляется намного лучше.
    > И в чём лучшесть?

    Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком.

    > Гиту, на самом деле, вообще по барабану какие
    > данные трекать - с блобами он справляется также как с текстом,
    > с большими блобами так же как с маленькими.

    А Вы проверьте. Возьмите видеоролик размером хотя бы в несколько десятков мегабайт, наложите титры названия на начало, чтобы нужно перекодировать всего один-два фрейма от ключевого кадра до ключевого. Затем десять раз поправьте текст, шрифт или местоположение этих титров, делая после каждой корректировки commit. В результате репозиторий Git окажется почти на порядок большего размера, чем у SVN.

    > Когда говорят о бинарных данных, обычно имеют в виду что не хотят
    > хранить всю их историю локально.

    Откуда такие экстрасенсорные провидения?

    > Для этого есть LFS

    И как же она заменит систему контроля версий?


     
     
  • 5.113, Аноним (38), 15:24, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком Вс... большой текст свёрнут, показать
     
     
  • 6.116, ptr (ok), 16:26, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >> Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком.
    > С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком.

    А считали как? Лёжа на диване по мухам на потолке? )))
    У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший объём, чем все остальные бинарные файлы вместе взятые.

    > Возможно это только до следующего gc. Если там действительно меняются только ключевые
    > кадры, общие части схлопнутся дельта компрессией при создании pack'а.

    Я же писал - проверьте. Не применяется дельта-компрессия в git к бинарным файлам более-менее приличного размера. Он тупо складывает их в LFS.

    > прочем, не понимаю зачем результат процессинга хранить в VCS. Хранится исходный
    > ролик и настройки субтитров.

    Потому что читать не умеете. Субтитры и титры названия ролика - очень даже разные вещи.
    Хотя могу предложить при редактировании "замедлить" или "ускорить" трехсекундный фрагмент.

    Я уже молчу про REDCODE или Apple ProRes с битрейтом в гигабиты, когда создание даже рекламного ролика может произвести сотню терабайт версий, если не выделять дельту в бинарных данных.

    > Что значит заменит систему контроля версий? Это часть git.

    Которая хранит каждую версию файла целиком, а не дельту. Про что и речь.

     
     
  • 7.119, Аноним (-), 17:21, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > А считали как? Лёжа на диване по мухам на потолке? )))
    > У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший
    > объём, чем все остальные бинарные файлы вместе взятые.

    Вот только при изменении видеофайла он тоже чаще всего меняется - почти на 100%, от и до. И вообще - система контроля версий исходников - все же не CDN для доставки видео.

    Бывают всякие смежные кейсы иногда. Но они редкие и в целом решаемые.

     
     
  • 8.125, ptr (ok), 17:53, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вы очень плохо знаете форматы видеофайлов Ещё с MPEG-1 модификация видеофайла н... текст свёрнут, показать
     

  • 1.6, Sm0ke85 (ok), 12:43, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Выпуск системы управления исходными текстами Git 2.54

    Заголовок не точный...

    '''
    Git — распределённая система управления Версиями.
    '''

     
     
  • 2.22, Аноним (21), 14:12, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точнее будет так. Система колективного написания кода.
     
  • 2.30, Аноним (38), 14:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Изначальный заголовок правильный, версиями тут никаким боком.
     

  • 1.7, Аркагоблин (?), 12:48, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.
     
     
  • 2.9, аврварвар (?), 12:55, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Новую СКВ сделать немножко проще, чем новое светило.
     
  • 2.14, Аноним (1), 13:36, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне плевать на монополию и какие-то там приложения, которые её используют (кстати, что это за приложения?). Я оцениваю по объективным признакам - она просто самая лучшая из тех, что существуют или когда-либо существовали: rcs, cvs, svn, fossil, hg
     
     
  • 3.15, Аркагоблин (?), 13:50, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Объективным качествам? Так древнеарамейский язык может тоже качественный, но если на нём не с кем общаться и его нельзя применить на практике, то и его качество бесполезно.
     
  • 3.17, Аноним (3), 14:00, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ну т.е. реального монополиста, perforce, ты в глаза не видел?
     
     
  • 4.36, Аноним (36), 15:10, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    При MS головного мозга что угодно может привидеться.
     
  • 2.16, Аноним (16), 13:56, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Она не лучшая СКВ, но монополий там, где действуют сетевые эффекты, избежать невозможно. А в СКВ они особенно сильны. Просто все проприетарщики кроме гитхаба оказались клиническими д********и и просрали все полимеры.
     
  • 2.26, Аноним (24), 14:27, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не посещала мысль, что монополия это плохо?
     
     
  • 3.34, Аноним (38), 14:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно плохо, это же в первом классе рассказывают. Безусловно нужно демонополизировать и пользоваться 2-3 несовместимыми VCS.
     
     
  • 4.54, Аноним (54), 16:44, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да один фюрер, один народ.
     
     
  • 5.75, Аноним (75), 18:27, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Котёнок с дверцей.
     
  • 3.76, Аноним (76), 18:32, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Они тут все ща системд топят, не поймут
     
  • 3.79, Аноним (79), 18:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Монополия в it-технологиях это какой-то оксюморон. Хотите - откапывайте для себя битбакеты, Линус со своим гитом вам не помешает.
     
  • 2.31, Аноним (38), 14:50, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.

    Ну да, а монополией её сделал лично Линус, потому что ходил по домам разработчиком и сносил им другие VCS. Нет, она монополия именно потому что лучшая. У hg были все шансы, он не взлетел. У большинства VCS-новоделов есть интероп с гитом, поэтому тоже все шансы, но кто ими пользуется?

     
     
  • 3.66, Аркагоблин (?), 17:48, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Монополией её сделал GitHub, а не Линус
     
     
  • 4.74, Аноним (74), 18:17, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При десятке аналогов упирающихся в корявость альтернатив.

    github и стал популярен из-за заточенности на git в отличии от других.

     
     
  • 5.87, Аноним (87), 21:37, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров, без лишней email-<предъявите ваш телефон и паспорт>-идиотии, а не наколеночным поделием, как остальные. Ну а что в GitHubе было - то и взлетело. Сам гитхаб прибил конкурентов за счёт тех же сетевых эффектов. В некоторые годы GitLab были намного лучше, но потом тоже хренеть начали, когда базу набирали.
     
     
  • 6.94, Аноним83 (?), 22:15, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там ничего что надо не найти.
     
     
  • 7.99, Аноним (99), 00:39, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Была нормальной до того, как они женились на MalwareScript.
     
  • 7.120, Аноним (-), 17:23, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там
    > ничего что надо не найти.

    Но на самом деле по своему крут для "большого" прожектманагемента. Если у тебя голимый патч - он конечно избыточен для этого. А если здоровый проект из кучи частей и проч - таки норм.

    Правда тормозной он конечно да. И барахла в нем много. В этом смысле если более лайтово хотелось - gogs-образные, типа gitea/forgejo/как их там (деривативы gogs) явно лучше.

     
  • 6.117, Аноним (74), 17:11, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров

    Очевидно, всяких форже ты не застал. Когда они были лидерами. У них был один недостаток. Они были не для git.

     
     
  • 7.121, Аноним (-), 17:24, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Очевидно, всяких форже ты не застал. Когда они были лидерами. У них
    > был один недостаток. Они были не для git.

    Они были - бесплатным хостингом для виндоблобов и характерными девами с CVS и SVN. За что и пострадали. Нормальные девелоперы выбрали git - а даунлоады они и сами себе нарулить с этим своим linux могут.

     

  • 1.8, Аноним83 (?), 12:54, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня rebase всегда какой то медленный, вот бы его ускорили.
     
     
  • 2.13, Аноним (13), 13:24, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    и зачем ты делаешь rebase?
     
     
  • 3.18, Аноним83 (?), 14:04, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что у меня набор локальных патчей, и я периодически подтягиваю с апстрима свежее и мне надо чтобы мои коммиты накатились сверху.
    В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.
    В моём представлении там всего то надо вызывать patch, потом git add, git commit. Учитывая что оно делается внутри одного бинарника то я ожидаю что с моми диффами в 1кб оно должно работать непрелично быстро.
     
     
  • 4.32, Аноним (38), 14:53, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже такое замечал на дереве портов FreeBSD (хотя это огромный реп). Стоило бы это попрофайлить, но пока недостаточно чешется.
     
     
  • 5.51, Аноним83 (?), 16:39, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так вот и не понятно, вроде ничего тяжёлого быть не должно.
     
  • 4.35, Аноним (41), 15:07, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.

    Помещаете в переменные $from указатель на последний коммит из родительской ветки, $to - последний нужный вам коммит, это можно автоматизировать, опираясь на ваш подход, после чего делаете
    git diff "$from..$to" | git apply
    git add .
    git commit -m 'one commit'
    Данная команда сожмёт всё в один коммит. Можно расписать более сложную логику, например через git log --name-only получать список имён, но это уже делать вам.

     
     
  • 5.53, Аноним83 (?), 16:41, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Мне один коммит не нужен и вреден.
     
  • 3.28, Аноним (27), 14:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты ветки мержишь? Серьёзно?
     
     
  • 4.42, Аноним (42), 15:39, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А как правильно?
     
  • 4.52, Аноним83 (?), 16:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.
    git -C /usr/ports/ pull --rebase upstream main
    git -C /usr/ports/ push -f origin main
     
     
  • 5.55, Аноним (54), 16:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ужасно
     
     
  • 6.63, Аноним (63), 17:37, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Ужасно

    Они там в BSD - CVS и SVN покусаны и поэтому напрочь не одупляют как работает git.

    Они и реплеят ударными темпами 100500 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто. Вот елси профайинг вместо этого затеять...

     
     
  • 7.114, Аноним (38), 15:33, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит реплеят и в чём разница с ребейзнуть Если ты про схлопнуть в оди... большой текст свёрнут, показать
     
     
  • 8.122, Аноним (-), 17:26, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ребэйз это и есть - реплей цепочки Гит сперва добавит новые комиты в цепочку, п... текст свёрнут, показать
     
  • 2.59, Аноним (-), 17:16, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня rebase всегда какой то медленный, вот бы его ускорили.

    А что ты с ним делаешь чтобы он был медленный? Реплеишь 100500 комитов? Ну так отребэйзь свои чудо-патчи на что-нибудь более новое - быстрее будет. Потому что меньше комитов реплеить.

     
     
  • 3.80, Аноним83 (?), 18:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Я выше написал как я делаю.
    Что вы предлагаете?
    Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.
     
     
  • 4.123, Аноним (-), 17:31, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.

    Ну так ребэйзни свой бранч с ними или что там у тебя на более новую версию апстрима - и число комитов которые надо аплаить при rebase радикально скостится.

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

     

  • 1.23, RM (ok), 14:24, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    git rip?

    из текста новости

    Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите,

    и ниже

    Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений

     
     
  • 2.33, Аноним (38), 14:54, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
     
  • 2.37, Аноним (1), 15:13, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У себя на локалхосте переписывай историю как хочешь.
     
     
  • 3.88, Аноним (88), 21:38, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Можно и не на локалхосте, а кому не нравится - утрутся.
     
  • 2.40, Аноним (41), 15:26, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так историю и так можно переписывать историю, через git rebase, а через git push --force можно и удалённую.
     
     
  • 3.61, Аноним (-), 17:18, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Так историю и так можно переписывать историю, через git rebase, а через
    > git push --force можно и удалённую.

    Можно. Но чаще всего лучше не стоит. Ибо если ты пушшанеш с форсом - у всех кто синкался оттуда - отъедет этот бранч. И его фикс потребует мануальщины. Т.е. вот именно незаметно подпихнуть левак - ну вот не. Это будет очень заметный и ломовой десинк, когда pull просто совсем не проходит - и ты либо мануально его захреначиваешь, либо думаешь что вообще с этйо ситуацией делать и выясняешь что там за нахрен с этим зеркалом.

     
     
  • 4.89, Аноним (89), 21:42, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Утрутся. Что вечно на SHA1 сидеть, или с километровыми блобами в репозитории, закомиченных в него недоумками по началу, а потом только сообразившими, что репозиторий именно из-за этого стал километровым? Или в очень большом репозитории с многолетней историей - с репозиторием на многие гига? Иногда практичнее чтобы те, кто PR отправили, утёрлись, git format-patch -1, git am ./*.patch, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать.
     
     
  • 5.107, Аноним (-), 12:43, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Таки можно и вечно сидеть SHA1 вообще не столько секурити фич сколько техническ... большой текст свёрнут, показать
     
  • 4.100, Аноним (100), 00:44, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Если pull с авто-rebase (как оно и должно быть), то ничего не отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
     
     
  • 5.124, Аноним (-), 17:35, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Если pull с авто-rebase (как оно и должно быть), то ничего не
    > отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.

    Да вот понимаешь ли, я могу чисто технически сделать push --force чего-то совсем радикально иного - на что ремоты - таки - десинхронизируются. И обучать их там всех правильно пул делать - ну тоже такое себе.

    Пожтому лично я push --force практикую только для мелких фич in flight с 1-3 интересантами. Если это не оно я подумаю о альтернативах.

     
  • 3.95, ыыыыы (?), 23:12, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нельзя делать git push --force
    Можно git push --force-with-lease --force-if-includes
     
     
  • 4.115, Аноним (38), 15:37, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Если пушишь ты один, то можно.
     

  • 1.45, Аноним (45), 15:45, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я бы сказал самая адекватная система Не плохая, не хорошая, а просто соответств... большой текст свёрнут, показать
     
     
  • 2.46, Александр (??), 16:05, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст.


    За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть.

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

    И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами.

    Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось

     
     
  • 3.62, Аноним (-), 17:22, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема ртути не в тренде, а с его сообществе -

    Ее проблема в том что вместо удачных технологических решений и решения проблем они удумали хайповать с своим питончиком с 1 стороны (получив бонусом 100500 проблем перфоманса которых гит не имел и рассказы как не тормозит на 20% лучше в каждой версии) - и потом еще подарок в виде питона 3 который федот - но не тот, что совсем уж их и вбило в гроб.

    А бонусом еще - аппелировать к необучашкам с CVS и SVN удумали - собрав все сливки общества.

     
     
  • 4.91, Аноним (91), 21:47, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - долго и нудно по объектику.
     
     
  • 5.108, Аноним (-), 12:48, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке -
    > долго и нудно по объектику.

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

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

     
  • 3.70, Аноним (45), 18:04, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Отчасти согласен, но всё перечисленное фактически уже следствие Даже уход mpm ... большой текст свёрнут, показать
     
  • 3.90, Аноним (90), 21:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Из Mercurial ущёл создатель, то есть его угроз засудить любого, кто посмеет сделать совместимый продукт, можно уже не опасаться?! Это офигенно, но как-то плохо верится, если бы ущёл создатель, то на опеннете была бы новость наверняка.
     
  • 3.102, Аноним (1), 10:23, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR

    Где сделать? Прям в ртути? А git'е оно как нормально сделано (именно в git-е, а не в гитхабе, гитлабе и тд)?

     
  • 2.47, Александр (??), 16:06, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст.


    За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть.

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

    И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами.

    Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось

     
  • 2.50, Джон Титор (ok), 16:29, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > В целом я считаю Mercurial лучше

    Я с этим согласен.

    > С развитием AI-агентов эти тренды только усиливаются, "главное быстро и работает", "агент разберется, я что сам эти команды набираю".

    Эх..

     
  • 2.64, Смузихлеб забывший пароль (?), 17:42, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Эти рассказы про "как надо" у ртути чем-то напоминают сказки про бздю и академических академиков которые якобы тоже делают только как правильно, как надо и как должно быть в отличие от линя.
    Но по сути, это именно что сказки. Дырок в бздях как в сыре и косяков/недоработок не меньше. А работа идёт медленней не потому что кто-то там слишком много думает и продумывает, а тупо потому что они получают меньше бабла, да и к самим системам сильно меньше интереса.

     
  • 2.129, Аноним (38), 18:43, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, его более бережное отношение к истории.

    Бережное отношение к истории - это сделать фичу, разбить её на topic коммиты отражающие стадии её внедрения и в таком виде влить. Те кто считают "бережным отношением к истории" необходимость фиксировать всю промежуточную работу, включая несобирающийся код, debug принты, закоммиченные по ошибке секреты и выходные файлы, не закоммиченные по ошибке исходники, к индустрии никакого отношения, действительно, не имеют.

     

  • 1.49, Джон Титор (ok), 16:25, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, помню у меня был коллега который любил подставить через изменение коммитов. Хорошо что ошибки при этом делал, которые можно доказать. Изменение истории конечно хорошо, если имеешь дело с адекватными людьми или ИИ, порой это нужно. Но я бы предпочел историю без изменений вообще - если что не так сделано - пусть будет новый комит с исправлениями. А если комментарий не такой как нужно, ну пусть будут какие-то заметки ещё, которые можно только добавлять. А перебазирование так вообще порой какие-то интересные вещи добавляет, особенно если через него делают PR. Зато совокупность комитов вместе и это вместо того чтобы делать сквош.
     
  • 1.60, Аноним (60), 17:16, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    VCS не стоят на месте, из последнего Ark выглядит шикарно
     
     
  • 2.73, Сладкая булочка (?), 18:16, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проприетарщина.
     

  • 1.65, Аноним (65), 17:43, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Обычному разрабу достаточно юзать любой гуй, хоть Git Extension на винде или встроенный в IDE. А эти извращения только релизеру, который пытается собрать проект от своих разрабов, и то если все пошло не плану и перемешалось так что черт ногу сломит.
     
     
  • 2.67, Аноним (65), 17:50, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    но если этот релизер или тимлид не участвовал сам в разработке, то никакие ухищрения с гитом не помогут ему правильно собрать ветки
     

  • 1.68, Аноним (68), 18:00, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Недавно, недели 3 назад, ещё вышла Jujutsu-VCS (jj-vcs) v0.40.0 — современная замена Git от Google, написанная на безопасном по памяти языке Rust
     
     
  • 2.69, Аноним (68), 18:00, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Она ещё совместима с Git
     
     
  • 3.72, Сладкая булочка (?), 18:12, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну вот git на posix shell https://git.sr.ht/~sircmpwn/shit  
     
  • 2.71, Сладкая булочка (?), 18:11, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > современная замена Git от Google

    А google то ее использует? Почему chromium использует git?

     
  • 2.92, Аноним (92), 21:48, 21/04/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.104, Аноним (1), 10:25, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Уж лучше got от OpenBSD, чем что-то от гугла... тем более на безопасном языке.
     

  • 1.82, Аноним (82), 19:22, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Годно, нужно, мощно, молодёжно. Использую в связке Astro + MDX + Git.
     
  • 1.126, Аноним (126), 17:57, 22/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гит обрастает хламом. С каждым новым релизом он всё дальше от бога. Идеал — когда нечего убрать и все рабочие потребности закрыты полностью. Гит идет обратной дорогой — наваливает все больше функций, а свою основную работу делает кое-как (не надо делать вид, что сломанная репа это целиком вина разработчика).

    Вот в коментах упоминают Ртуть. Она почти мертва и мало кем используется, но при этом в ней есть всё что нужно для работы.  Я пользуюсь ей для своих проектов. Ртуть ни разу не делала мне голову в отличии от гита. Всё таки смерть — это настояший релиз программы. Миллионы мух летят дальше на новый релиз более модной технологии, а ты ценишь покой, когда в "умершей" программе всё изучено и работает без суеты.

     
     
  • 2.130, Гуманоид (?), 01:45, 23/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогично, для себя только ртуть. Меркуриал сделан для людей. Git сделан для погромистов.  
     

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



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

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