chexit/airdef
1
0
Fork 0
Code Issues 22 Pull Requests Actions Packages Projects 1 Releases 54 Wiki Activity

[enhancement] Вынести форк Horizon в отдельный репозиторий и подключить к AirDef через git submodule #104

New Issue
Open
opened 2026-10-30 11:05:01 +00:00 by chexit · 1 comment
chexit commented 2026-10-30 11:05:01 +00:00
Owner
Copy Link
Copy Source

🤖 Filed by Codex, AI-агент Владимира (chexit).

Решение пользователя и предварительное условие

Вынести наш форк Horizon в самостоятельный репозиторий и подключить его к AirDef как git submodule по пути horizon/ с фиксацией конкретного коммита.

Репозиторий создаст Владимир и передаст URL исполнителю позже. Название horizon-airdef — пример, не уже существующая репа. Для выполнения нужен <FORK_REPOSITORY_URL>; создание репозитория в эту задачу не входит. Нельзя подставлять придуманный URL или публиковать коммиты в случайно выбранную репу.

Основание и границы

В рассмотренном состоянии движок воспроизводится из HORIZON_COMMIT и horizon-patches/, подготовкой управляет tools/airdef.py fork. При развитии собственного рендера, capture/export, модового API и акустики полноценная история форка удобнее постоянно растущего patch stack.

В новой репе живут исходники движка, его SDK/WIT, общие возможности и собственные проверки/сборки. В AirDef остаются симуляция и контент мода, интерфейс, сценарии, ассеты и использование SDK. Отдельную третью репу для SDK/контрактов сейчас не вводить.

Этапы миграции

  1. Зафиксировать исходное состояние. Перед переносом проверить актуальные ветки, патчи и незакоммиченные изменения. Сохранить полную историю upstream Horizon и наши коммиты с авторством/лицензиями; существующую подготовленную ветку форка можно использовать как исходник после проверки. Убедиться, что перенос включает все действующие патчи и локальные доработки, не публиковать target/, игровые ресурсы, домашнюю папку запуска или служебные stamp-файлы.
  2. Опубликовать движок в предоставленную репу. Сохранить понятную связь с upstream и способ получать его обновления. Проверить, что выбранный коммит доступен на remote, прежде чем ссылаться на него из AirDef. Обновление версии upstream — самостоятельная #72; не совмещать с переносом без необходимости.
  3. Подключить horizon/ как сабмодуль. .gitmodules хранит доступный URL и путь, gitlink — точный SHA форка. Привести .gitignore и старую подготовку каталога в соответствие. Существующий checkout и пользовательские изменения сначала безопасно сохранить; никаких автоматических destructive reset/clean. Относительный путь ../horizon/crates/horizon-mod-sdk из Cargo.toml мода по возможности сохранить.
  4. Обновить инструменты. tools/airdef.py fork/эквивалент инициализирует и разворачивает закреплённый сабмодуль. game, mod, all работают из чистого checkout. Обычная сборка не подтягивает плавающий latest/main и не накладывает прежний стек патчей поверх уже готового форка. Изменённый рабочий checkout не перезаписывается молча. Совместимость packer/SDK дополнить в рамках #102.
  5. Обновить CI и релизы. Checkout получает сабмодули; проверить mod/game/desktop workflows и доступ к новой репе, если она приватная. Credentials только через штатные secrets/настройки CI, не в URL .gitmodules. Артефакты указывают SHA AirDef и SHA движка. Движок получает собственный lifecycle сборок; совместимая пара версий остаётся воспроизводимой.
  6. Перевести разработку на один источник правды. Новые engine-правки коммитятся в репе форка; AirDef отдельным коммитом обновляет gitlink после проверки. Старые патчи и старый pin не должны оставаться второй независимо поддерживаемой версией движка. Архивировать/убирать их только после подтверждения эквивалентности переноса и сборок; upstream baseline при необходимости хранить уже как метаданные форка.
  7. Документация. Описать git clone --recurse-submodules, восстановление зависимости через git submodule update --init --recursive, обновление закреплённого SHA и порядок двух связанных PR. Для правок внутри сабмодуля — рабочая ветка; сначала push движка, затем ссылка в моде. Описать возврат к ранее закреплённой версии.

Приёмка

  • Чистый recursive clone получает ровно проверенный движок без ручного наложения патчей; обычный clone восстанавливается документированной командой/скриптом.
  • Новый commit в main движка сам по себе не меняет сборку старого AirDef. Обновление gitlink видно отдельным diff/коммитом.
  • До/после миграции исходники движка эквивалентны по содержательным файлам; существующие native-тесты, сборка WASM-мода и действующие проверки движка проходят. Платформенные workflows корректно получают pinned source.
  • Оба remote содержат все коммиты, на которые ссылается релиз; токенов/vanilla-ресурсов в истории новой репы нет.
  • Есть понятная таблица совместимых сборок/метаданные и инструкция локальной разработки; старые SDK-пути не ломаются неожиданно.

Связано: #102 (воспроизводимость/версии SDK и packer), #103 (архитектурная дорожная карта). Акустика #95/#96 и следующие engine-возможности после миграции разрабатываются уже в отдельной репе форка.

🤖 Filed by Codex, AI-агент Владимира (chexit). ### Решение пользователя и предварительное условие Вынести наш форк Horizon в самостоятельный репозиторий и подключить его к AirDef как **git submodule** по пути `horizon/` с фиксацией конкретного коммита. **Репозиторий создаст Владимир и передаст URL исполнителю позже.** Название `horizon-airdef` — пример, не уже существующая репа. Для выполнения нужен `<FORK_REPOSITORY_URL>`; создание репозитория в эту задачу не входит. Нельзя подставлять придуманный URL или публиковать коммиты в случайно выбранную репу. ### Основание и границы В рассмотренном состоянии движок воспроизводится из `HORIZON_COMMIT` и `horizon-patches/`, подготовкой управляет `tools/airdef.py fork`. При развитии собственного рендера, capture/export, модового API и акустики полноценная история форка удобнее постоянно растущего patch stack. В новой репе живут исходники движка, его SDK/WIT, общие возможности и собственные проверки/сборки. В AirDef остаются симуляция и контент мода, интерфейс, сценарии, ассеты и использование SDK. Отдельную третью репу для SDK/контрактов сейчас не вводить. ### Этапы миграции 1. **Зафиксировать исходное состояние.** Перед переносом проверить актуальные ветки, патчи и незакоммиченные изменения. Сохранить полную историю upstream Horizon и наши коммиты с авторством/лицензиями; существующую подготовленную ветку форка можно использовать как исходник после проверки. Убедиться, что перенос включает все действующие патчи и локальные доработки, не публиковать `target/`, игровые ресурсы, домашнюю папку запуска или служебные stamp-файлы. 2. **Опубликовать движок в предоставленную репу.** Сохранить понятную связь с upstream и способ получать его обновления. Проверить, что выбранный коммит доступен на remote, прежде чем ссылаться на него из AirDef. Обновление версии upstream — самостоятельная #72; не совмещать с переносом без необходимости. 3. **Подключить `horizon/` как сабмодуль.** `.gitmodules` хранит доступный URL и путь, gitlink — точный SHA форка. Привести `.gitignore` и старую подготовку каталога в соответствие. Существующий checkout и пользовательские изменения сначала безопасно сохранить; никаких автоматических destructive reset/clean. Относительный путь `../horizon/crates/horizon-mod-sdk` из Cargo.toml мода по возможности сохранить. 4. **Обновить инструменты.** `tools/airdef.py fork`/эквивалент инициализирует и разворачивает закреплённый сабмодуль. `game`, `mod`, `all` работают из чистого checkout. Обычная сборка не подтягивает плавающий latest/main и не накладывает прежний стек патчей поверх уже готового форка. Изменённый рабочий checkout не перезаписывается молча. Совместимость packer/SDK дополнить в рамках #102. 5. **Обновить CI и релизы.** Checkout получает сабмодули; проверить mod/game/desktop workflows и доступ к новой репе, если она приватная. Credentials только через штатные secrets/настройки CI, не в URL `.gitmodules`. Артефакты указывают SHA AirDef и SHA движка. Движок получает собственный lifecycle сборок; совместимая пара версий остаётся воспроизводимой. 6. **Перевести разработку на один источник правды.** Новые engine-правки коммитятся в репе форка; AirDef отдельным коммитом обновляет gitlink после проверки. Старые патчи и старый pin не должны оставаться второй независимо поддерживаемой версией движка. Архивировать/убирать их только после подтверждения эквивалентности переноса и сборок; upstream baseline при необходимости хранить уже как метаданные форка. 7. **Документация.** Описать `git clone --recurse-submodules`, восстановление зависимости через `git submodule update --init --recursive`, обновление закреплённого SHA и порядок двух связанных PR. Для правок внутри сабмодуля — рабочая ветка; сначала push движка, затем ссылка в моде. Описать возврат к ранее закреплённой версии. ### Приёмка - Чистый recursive clone получает ровно проверенный движок без ручного наложения патчей; обычный clone восстанавливается документированной командой/скриптом. - Новый commit в main движка сам по себе не меняет сборку старого AirDef. Обновление gitlink видно отдельным diff/коммитом. - До/после миграции исходники движка эквивалентны по содержательным файлам; существующие native-тесты, сборка WASM-мода и действующие проверки движка проходят. Платформенные workflows корректно получают pinned source. - Оба remote содержат все коммиты, на которые ссылается релиз; токенов/vanilla-ресурсов в истории новой репы нет. - Есть понятная таблица совместимых сборок/метаданные и инструкция локальной разработки; старые SDK-пути не ломаются неожиданно. Связано: #102 (воспроизводимость/версии SDK и packer), #103 (архитектурная дорожная карта). Акустика #95/#96 и следующие engine-возможности после миграции разрабатываются уже в отдельной репе форка.
chexit added the area:architecturearea:toolingpriority:P2type:enhancement labels 2026-10-30 11:05:01 +00:00
chexit commented 2026-11-02 18:04:17 +00:00
Author
Owner
Copy Link
Copy Source

🤖 Agent: Codex — работа Владимира (chexit).

Реализован перенос в отдельный https://gitea.maoniao.team/chexit/horizon-airdef, ветка airdef; AirDef использует точный git submodule SHA. Удалены 44 patch-файла и HORIZON_COMMIT как второй источник; история сохранена в форке. Миграция, актуальный pin.

python tools/airdef.py all сам инициализирует зависимость и переводит старый чистый standalone clone в submodule без удаления его веток. Dirty checkout при несовпадающем SHA останавливает обновление. CI checkout обновлён. Проверены настоящий recursive clone и 3 Git regression fixtures: pin старого SHA, сохранение dirty checkout, legacy absorb с локальной веткой.

Windows: git fetch origin, git switch kimi-work, git pull --ff-only, python tools/airdef.py all, python tools/airdef.py play. На Windows здесь не запускалось; инструкции и перенос проверены на macOS.

Issue оставлен открытым согласно просьбе автора.

🤖 Agent: Codex — работа Владимира (chexit). Реализован перенос в отдельный [https://gitea.maoniao.team/chexit/horizon-airdef](https://gitea.maoniao.team/chexit/horizon-airdef), ветка `airdef`; AirDef использует точный git submodule SHA. Удалены 44 patch-файла и HORIZON_COMMIT как второй источник; история сохранена в форке. [Миграция](https://gitea.maoniao.team/chexit/airdef/commit/4761ae7), [актуальный pin](https://gitea.maoniao.team/chexit/airdef/commit/6397299). `python tools/airdef.py all` сам инициализирует зависимость и переводит старый чистый standalone clone в submodule без удаления его веток. Dirty checkout при несовпадающем SHA останавливает обновление. CI checkout обновлён. Проверены настоящий recursive clone и 3 Git regression fixtures: pin старого SHA, сохранение dirty checkout, legacy absorb с локальной веткой. Windows: `git fetch origin`, `git switch kimi-work`, `git pull --ff-only`, `python tools/airdef.py all`, `python tools/airdef.py play`. На Windows здесь не запускалось; инструкции и перенос проверены на macOS. Issue оставлен открытым согласно просьбе автора.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:architecture
Границы модулей, контракты, состояние сессии и развитие общей архитектуры
 area:audio
Звуки, громкость, задержка распространения и аудиоассеты.
 area:logistics
Боезапас, склады, ТЗМ, обслуживание и заявки снабжения.
 area:persistence
Сохранение, загрузка, сценарии и изоляция состояния между мирами.
 area:rendering
Шейдеры, GPU-ресурсы, освещение, геометрия, эффекты и рендер API.
 area:simulation
Полёт, обнаружение, планирование налётов, наведение, повреждения и игровая логика.
 area:tooling
Сборка, CI, тесты, инструменты разработки и инструкции установки.
 area:ui
HUD, радары, мониторы, меню, текст и интерфейс реплеев.
 needs:profiling
До существенной оптимизации измерить стоимость в игре/WASM/GPU; native-оценки и чтение кода не заменяют профиль Mac.
 priority:P1
Первый проход: поломки боя/сохранения и основной запрос по FPS. Гипотезы производительности сначала профилировать.
 priority:P2
Следующий проход: обычные баги, безопасные улучшения и вспомогательные оптимизации.
 priority:P3
Позже: косметика, новые удобства, латентные дефекты и дорогие оптимизации без подтверждённой необходимости.
 type:bug
Подтверждённый дефект поведения или обработки состояния; способ проверки указан в issue.
 type:docs
Документация, инструкции и соответствие описания текущему коду.
 type:enhancement
Новое поведение, баланс или улучшение удобства.
 type:performance
Оптимизация затрат CPU/GPU, памяти, I/O или передачи данных; не обещает прирост без замера.
No Label area:architecture area:tooling priority:P2 type:enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
chexit
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: chexit/airdef#104
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?