Future-proofing the example code
- 主要言語
- Assembly
- スター
- 179
- フォーク
- 64
- 平均マージ
- 7日 22時間
- マージ済み PR(30日)
- 1
説明
Parts II and III will have the reader (and thus, the writer as well) working iteratively on a codebase. Where it gets iffy is that any change made to earlier lessons must be consistently reflected in later lessons. (This could happen for example because an earlier lesson is amended to make "room for" a later one, to update the syntax for a newer RGBDS version etc.)
Propagating these changes throughout the tutorial, where they would be presented "inline", would be a massive pain. Instead, I suggest the codebase should be checked out into Git, and inline code examples pulled from that repo.
This does get somewhat involved in several ways (e.g. ensuring that all referenced commits are reachable from the `master` branch, keeping referenced line numbers consistent when rebasing, etc.), but I think is essential if we want to avoid the tutorial irremediably bit-rotting in the longer term.
The concrete solution, I'd say, is to build a mdBook preprocessor (either stand-alone, or as part of the [bundled one](https://github.com/ISSOtm/gb-asm-tutorial/tree/master/preproc)), that is able to include portions of files (like [the default `links` preproc is able to](https://rust-lang.github.io/mdBook/format/mdbook.html#including-files)), but picking a version of that file in a specific commit. `libgit` integration is desirable so as to avoid a ton of slow `git checkout`s, but not necessary—the priority is to it make work.
コントリビューションガイド
調査の方向性
リポジトリの preproc ディレクトリから始め、そこに同梱されているプリプロセッサと mdBook のデフォルトの links プリプロセッサを比較します。参照されているコミットを master から到達可能な状態に保つ方法と、含めるファイルの一部分をどのように選択すべきかを調査します。チュートリアルが、手動で繰り返し更新することなく、指定されたコミットからインラインコード部分を取得できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- git
- 領域
- documentation, tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 30/100