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 <[email protected]>"
    
  • В команду "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 обязательно


Обсуждение (96) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:31, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Лучшая система контроля версий ever.
     
     
  • 2.2, Аноним (2), 12:33, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –3 +/
    cvs лучше
     
     
  • 3.3, Аноним (3), 12:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, рар
     
  • 3.27, Аноним (27), 14:38, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    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 [^] [^^] [^^^] [ответить]  
  • +/
    Ушёл с меркуриала - ни о чём не жалею
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что вы сравниваете лучший и не лучший словно кроме Git есть реальные ... текст свёрнут, показать
     
  • 3.56, Аноним (-), 17:01, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну так был sourceforge, тормозил с гитом по упора, сватая отличные CVS и SVN -... большой текст свёрнут, показать
     
     
  • 4.77, Аноним (77), 18:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >SVN

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

     
  • 3.98, OpenEcho (?), 23:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подумать есть выбор.

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

     
  • 2.5, Аноним (5), 12:43, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Лучшая система контроля версий ever.

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

     
     
  • 3.24, Аноним (24), 14:25, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Юникс послал гну и ядро и так появился Линукс.
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • –3 +/
    ... называется hg.
     
     
  • 3.58, Аноним (-), 17:13, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > ... называется hg.

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

     
  • 2.44, Аноним (-), 15:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    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

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


     

  • 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 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не посещала мысль, что монополия это плохо?
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Монополия в 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.
     

  • 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 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто. Вот елси профайинг вместо этого затеять...

     
  • 2.59, Аноним (-), 17:16, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня rebase всегда какой то медленный, вот бы его ускорили.

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

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

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

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

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

    и ниже

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

     
     
  • 2.33, Аноним (38), 14:54, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
     
  • 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, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать.
     
  • 4.100, Аноним (100), 00:44, 22/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Если pull с авто-rebase (как оно и должно быть), то ничего не отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
     
  • 3.95, ыыыыы (?), 23:12, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нельзя делать git push --force
    Можно git push --force-with-lease --force-if-includes
     

  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - долго и нудно по объектику.
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Эти рассказы про "как надо" у ртути чем-то напоминают сказки про бздю и академических академиков которые якобы тоже делают только как правильно, как надо и как должно быть в отличие от линя.
    Но по сути, это именно что сказки. Дырок в бздях как в сыре и косяков/недоработок не меньше. А работа идёт медленней не потому что кто-то там слишком много думает и продумывает, а тупо потому что они получают меньше бабла, да и к самим системам сильно меньше интереса.

     
     
  • 3.103, Аноним (1), 10:24, 22/04/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     

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

  • 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.
     

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



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

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