Hacker News Digest

DeltaDB — новая система контроля версий, фиксирующая каждый шаг разработки в реальном времени и привязывающая его к разговору, который её породил. Каждая операция получает уникальный идентификатор, что позволяет в любой момент «откатиться» к конкретному состоянию кода и увидеть, какая часть диалога её сформировала.

Цитата: «Каждая строка кода — это следствие разговора».

Ключевые возможности: мгновенный откат к любой точке истории, возможность «развивать» ветки от любой промежуточной версии, а также совместная работа в режиме «живого» обсуждения — коллега может присоединиться к процессу, задавать вопросы и вносить правки, не дожидаясь завершения коммита. Цифра: в тестах DeltaDB ускоряет поиск причины ошибки на 40 %.

DeltaDB может быть полезен для обучения ИИ-моделей, но многим разработчикам он не нужен — его разработка вызывает сомнения, так как не решает явных проблем. Пользователи считают, что разработчики Zed должны приоритизировать исправление багов, добавление недостающих функций и внедрение уже существующих решений из других редакторов (например, JetBrains IDE), а не разработку новых систем контроля версий. Текущее состояние Zed оставляет желать лучшего.

В Git существует три отдельных механизма для исключения файлов, работающих на разных уровнях. Основной — .gitignore, который хранится в репозитории и попадает в коммит; второй — .git/info/exclude, локальный для конкретного репозитория и не версионируется; третий — глобальный файл ~/.config/git/ignore, действующий для всех репозиториев на машине. Благодаря этому можно игнорировать как общие артефакты (например, .DS_Store), так и личные временные файлы, не засоряя .gitignore.

Для проверки, какой из файлов игнорирует конкретный путь, используется git check-ignore -v <файл>. Если правило берётся из .gitignore, вывод выглядит как .gitignore:1:.DS_Store .DS_Store; из .git/info/exclude — .git/info/exclude:7:.DS_Store .DS_Store; при использовании пользовательского глобального файла — /Users/nelson/.gitignore_global:1:.DS_Store .DS_Store. Если ничего не игнорирует файл, команда ничего не выводит. Кроме того, глобальный файл можно задать под другим именем, например .gitignore_global, командой git config --global core.excludesFile ~/.gitignore_global, а вернуть стандартный режим — git config --global --unset core.excludesFile. Это удобно, если хочется хранить отдельный набор правил, например, исключать все файлы с расширением .log или каталог build. Таким образом, гибкость игнорирования расширяется за пределы обычного .gitignore.

• .gitignore — обычный способ игнорировать файлы в репозитории, но его нельзя использовать для игнорирования глобально на всех проектах.
• Существует глобальный игнор‑файл (~/.config/git/ignore или ~/.gitignore_global), который игнорирует файлы для конкретного пользователя, а не для всей машины.
• Для локального игнорирования без изменения репозитория можно использовать .git/info/exclude или файл в .git (например, scratch/.gitignore с *).
• Иногда полезно добавить правила в .gitattributes (например, игнорировать package-lock.json) или использовать git update-index --assume-unchanged/--skip-worktree для временного отслеживания файлов.

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Любой сервер с SSH-доступом может стать Git-сервером. Достаточно клонировать репозиторий через git clone ssh://username@hostname/path/to/repo, а для отправки изменений добавить на сервере git config receive.denyCurrentBranch updateInstead. Этот подход идеален для синхронизации кода между устройствами или работы с файлами на сервере без задержек.

Для публикации кода через веб нужно указать веб-серверу путь к Git-репозиторию и выполнить git update-server-info. Чтобы это происходило автоматически, можно настроить хук post-update, который будет запускать эту команду после каждого обновления. Хуки также могут использоваться для запуска статических генераторов сайтов — автор блога успешно применяет этот метод для своего сайта, получая преимущества локальной работы и автоматического развёртывания.

Такой подход обеспечивает встроенное резервное копирование: при поломке сервера данные останутся на ноутбуке, и наоборот. Git-трекинг версий предотвращает случайные удаления и упрощает отладку ошибок.

• Обсуждение охватило широкий спектр тем: от фундаментальных концепций (bare-репозитории, push-в-в-ssh, хуки) до практических аспектов (самостоятельный хостинг, CI/CD, бэкапы).
• Участники подчеркнули, что Git изначально задумывался как распределённая система без необходимости в централизованном хостинге, и что это встроено в его архитектуру.
• Были упомянуты различные инструменты и практики, такие как git init --bare, git daemon, git-shell, хуки и т.д., как часть более широкого обсуждения о том, как Git может быть использован для хостинга репозиториев.
• Обсуждались также более широкие темы, такие как философия open-source, централизация против децентрализации, и как GitHub/GitLab и подобные платформы влияют на разработку ПО и сообщество.

В 2012 году автор, работая с Ruby и Rails, обнаружил Rust и увидел в нём потенциал. Он оценил три ключевых фактора успеха языка: рыночную нишу (безопасность памяти без сборщика мусора как инновация в низкоуровневом программировании), команду (поддержку Mozilla) и пользователей (планы использовать Rust в Firefox). Этот подход помог ему принять решение присоединиться к проекту Rust, написать руководство "Rust for Rubyists" и в итоге войти в команду.

Сейчас автор применяет тот же анализ к jj — новой системе контроля версий, написанной на Rust. Как и в случае с Rust, он видит у jj хорошую рыночную нишу (возможность работать с Git-репозиториями для постепенного внедрения), сильную команду (Google использует jj) и растущую пользовательскую базу. На первой конференции jj создатель马丁 отметил важный аспект, хотя детали в статье не раскрываются.

• Обсуждение в основном вращается вокруг того, что Git остаётся доминирующим, но jj и другие инструменты могут предложить улучшенный UX и модель данных, что делает их привлекательными для некоторых пользователей.
• Участники обсуждали, что отсутствие интеграции с GitHub и другими платформами может быть препятствием для широкого внедрения jj.
• Некоторые участники выразили обеспокоенность относительно того, что новые системы могут не поддерживать критические функции, такие как LFS и инструменты для работы с бинарными файлами.
• Обсуждались также вопросы документации, обучения и поддержки сообщества, которые могут быть недостаточными для новых систем.
• Наконец, обсуждались личные мотивации и карьерные шаги, включая влияние на открытый исходный код и его влияние на развитие инструмента.