リポジトリを作り直した件
公開日:2025/08/24
適当にリポジトリを作るのはよくない。
経緯
http であそぼうは、リポジトリよりも先に本を書いており、コード自体も一時プロジェクトとして tmp で作成してました。
ところが、当初の目的と反して記事的にもプロジェクト的にも大きくなったので、急遽リポジトリの作成をしました。
first-commit として、できてたコードをそのまま上げてしまったので、のちに後悔しましたとさ。
ブランチきれないじゃん!
http であそぼうでは、クレートを試験するために別のプロジェクトとして httparse、reqwest を試そうとしました。
- ex/reqwest ブランチ
- ex/httparse ブランチ
first-commit が空であれば、そこから分岐して終わりだった。
ところが first-commit が埋まってたのでブランチ初めのコミットが「既存ファイル削除」となってしまったのですね。
note
ちなみに、全く別のリポジトリにしなかったのは、リンク誘導が楽だからとか、リポジトリ名考えるのがめんどかったからです。
note
いつも通りぼっち保守リポジトリであるので、rebase による副作用は考えなかったです。
また、issue などの機能には手をつけてなかったので、最悪リポジトリ削除という選択肢もあり得てます。(てか結論そうした)
first-commit を分離する -> 失敗した
仕方なくgit rebase -i --root
で first-commit を分離しようとしました。
git reset
git reset
git reset --mixed
...
reset されねぇ!
reset って手前のコミットの状態に戻すコマンドだと思うのですが、手前のコミットが存在しないので不可能なのです。
update-ref する
qiita曰く、update-refを行えば近いことができる模様。
そう思ってました。
rebase に失敗した
rebase に失敗しました。
正しくは過去のコミットの削除に失敗しました
rebase ってコミットを修正後、新しく作り直す(一番後ろに修正後のコミットを追加、のちに修正前のコミットを削除)するのですが、追加されたのちに削除できずエラーとなりました。
update-ref が絡んでそうなエラーが出てましたね。
結局リポジトリ削除
結局リポジトリを削除して、必要な履歴を cherry-pick で引っこ抜いてきました。
まとめ
せめて first-commit は空、もしくは Readme オンリーにしようと思いました。
今回の用途は特殊すぎるけど、普通に rebase する時も大変そうだったので。