最終更新: 2019-04-12T22:46+0900
コミット構成を変えるために複数のブランチを作成したりマージしたりなんだりしてから作業用のブランチを整理したら、再構成後のブランチまで一緒に削除してしまっていた！ １時間の作業成果！
.git/objects/*/* から一番新しいコミットオブジェクトをサルベージしてなんとかなった。サルベージっていうのは git checkout -b MyAnHour xxx(全部で40桁)xxx すること。
コミットの再構成は git rebase でもできるらしい。削除・入れ替え・併合は当然。edit オプションを使えばコミットの分割もできるとか。
そういえばまだ reflog って知らない。
最終更新: 2021-05-07T19:12+0900
「6.3 GitHub - プロジェクトのメンテナンス - プルリクエストの参照」
GitHub のリポジトリを git clone --mirror してると refs/pull/xxx/head, refs/pull/xxx/merge という見慣れない refs がダウンロードされてくる。
これはそのまま refs/pull/xxx/head という名前でコミットオブジェクトが参照でき、git fetch や git pull の引数として利用できる。
リンク先で書かれていることに従って .git/config の <remote> 名のセクションで fetch = +refs/pull/*/head:refs/remotes/<remote>/pull/* というマッピングルールを付け加えると、<remote>/pull/xxx というブランチ名が利用できるようになる。git branch --remotes が大量の PR ブランチで押し流されることと、コミットオブジェクトの大群がダウンロードされてくることが気にならないなら、便利。
PR を出した人のリポジトリを URL なり登録したリモート名なりで参照することなく、git checkout -b PRxxx <remote>/pull/xxx するだけでプルリクエストが試せる。
PR は誰でも出せるものであるからして、問題のあるコードを簡単にダウンロードできてしまう方法だという自覚は必要。
git fetch <remote> したら新規 PR が [new ref] として降ってくるし、更新があった PR の番号もわかる。そこで git show <remote>/pull/xxx すると最新のコミットの内容から PR をチラ見できる。
gitk するとあれやこれやのマージコミットの横に remotes/<remote>/pull/xxx というラベルが付いてどの PR 由来のコミットかがわかる。数が多すぎてちょっとうるさいけど。
いやあ便利。
大量の PR ブランチに押し流されるのが嫌なら、最初に書いた fetch におけるマッピングルールを工夫して、<remote> におけるコミットオブジェクトへの参照名(refs/pull/xxx/head)をそのままローカルで利用する参照名としてダウンロードできると思う。ローカルの名前なら fetch, pull に限らない幅広いサブコマンドで利用できるでしょう。
やってみた。同じ場所に同じように fetch = +refs/pull/*/head:refs/pull/<remote>/* と書いたら同じように [new ref] が降ってきた。refs/pull/xxx/head は GitHub にあるリポジトリで利用できる名前だけど、refs/pull/<remote>/xxx は同じコミットオブジェクトを指すローカルの名前。git show refs/pull/<remote>/xxx でコミットの内容が見られるのはさっきと同じだけど、git checkout -b PRxxx refs/pull/<remote>/xxx するまではブランチとしては存在しない。gitk するとこれまで見たことのない背景色で pull/<remote>/xxx というラベルが付いていた。コマンドの引数で refs/ は省略できるみたい。
refs/heads, refs/remotes, refs/tags の基盤となる refs という機能が Git にはあって、挙げた３つは Git が標準的に利用している。refs/pull は GitHub が私的に利用している。gitk はすべての refs をラベルとして表示することができ、既知の種類のラベルに特別の色分けを施していただけなのだろう。
あまり区別せずにブランチって書いてきたけど、最初の fetch ルールで作成するのはローカルのリポジトリで定義したリモート名の下にあるとするリモートブランチ。ローカルのブランチではないし、リモートにそのままの形で実在するブランチでもない(fetch 後に削除されたかもしれないし、fetch のマッピングルールによって名前を変えたのは自分だ)。実際のところ refs と何が違うのかわからない。git branch -r でリストできるかどうかの違いしか今のところわからない。git push の既定の動作に違いが現れるのかもしれないけど、そういう自動化は無効にしてるから本当に違いがない。
たぶん今日ここに書いたことは、わかる人はすでにわかってる、わからない人には何の参考にもならない、そんな内容だと思う。こち亀で「OS」だの「インストール」だのといった専門用語(※そういう時代！)が飛び交っていて、柱をびっしり埋める脚注を読んでもさっぱりわからなかった回のように。
今回発表された「Wowma!」利用者に対する還元は、楽天との提携によって強化されるWowma!の取り扱いを増やしつつ、値下げへの要請にも応える狙いがありそうです。」は寝言で間違いない。逆に、通信料を原資もしくは呼び水にして通販を割り引いてるだろ、これ。
最終更新: 2019-04-12T22:47+0900
プルリクエストの元になったブランチは、自分の GitHub リポジトリにプッシュしたものが即座にリクエスト先にも反映される点で、公的なブランチだといえる。
プルリクエストに対する修正を事前に私的にテストするために、プルリクエストを意図せず Work in progress 状態にしないために、どういう手順をとるか。
前提として AppVeyor といった CI が自分の GitHub リポジトリと連動しており、GitHub にプッシュしなければテストが完了しないという事情がある。
元になったブランチから私的実験ブランチを派生させるのがいいと思う(これって常識？)。実験して結果を確かめたものを公的ブランチにマージし、必要ならリベース(並べ替え・併合)し、プッシュする。あるいは実験ブランチの段階でリベースによりコミットの取捨選択と整理を行っておき、公的ブランチにはマージとプッシュだけをしてもいい。
最終更新: 2019-04-12T22:47+0900
操作対象で分かれてるよね。そんで fetch, pull, push 以外はオフラインと考えていい。
rebase の用途は主にマージの１手段としてと、ブランチの付け替えと、コミットの整理とがあるけど、やってることはコミットオブジェクトの書き換え(※)であると。
※これは概念的な理解であって、もちろんコミットオブジェクトは名前に対して不変であるし、実際には refs/heads の書き換えも行っているはず。
ローカルブランチの削除は branch で行うけど、リモートリポジトリにあるブランチの削除を行うのは push であると。
git pull --all とかやっちゃうと操作対象はブランチだから、現在のブランチにマージコミットが追加されておろおろしてしまうと。git fetch --all にしよう。
もちろんオプションによりブランチだった対象がタグになったりするし、branch サブコマンドでリモート(※ローカルのリポジトリにフェッチ済みのリモート)にあるブランチを表示したりもできる。あくまでも基本の対象ではある。
最新バージョンはご使用のシステムに対応していません」だもんなあ。■Vivaldi はインストールできたし、GitHub も使用できた。■Windows Vista は発売直後に買ったけど、10 はいらないんだよなあ。ほら>「【Windows 10】「勝手にLINEがインストールされていた」の声が増加中（2018年11月11日） | LINEの仕組み」■かくいう Vivaldi も背後のウィンドウとの境目がわからないフラットデザイン(デザイナー仕事しろ！)だけどな。■枠が欲しけりゃ「通常のウィンドウを使用する」という設定が Vivaldi にはあるんだよ。でも、右上のコントロール(＿□✖)のサイズが設定とは異なり小さすぎるし、Aero Glass でない単色の青だしで、全然「通常のウィンドウ」ではない。
if (this) {} else {} みたいなコードが通らなくなる。ヌルポインタかどうかを確かめることには問題がないし、仮想関数を呼び出そうとしたりしない限りは C++ 的にも許されている雰囲気を感じていたのだけど、デバッグ情報が this 付近にあると期待されていたりしてそれが問題につながるんだろうか。■ -g オプションだけなら OK だった。■ -Os でもアウトだったから問題は -Os, -Og という最適化オプションにある。許されてはいなかったのか……。■「C++ の標準としては未定義動作です」
♭ べる運転手運転拒否で客放置