git lfs migrate で Git-LFS 移行したときのメモ

Mercurial(Hg)からGit移行移行したついでに、ほぼ1GBとかあるリポジトリ*1をGit-LFSに移行した際のメモです。

Git-LFSを扱えるサービスとしてはBitbucket CloudよりもGitlab.comの方が制限が緩かったので、そちらへの移行も同時に行いました。

ja.confluence.atlassian.com

gitlab.com

作業環境: Windows 10 + Git for Windows(+Git Bash,Git LFS)

0. BFGを使わなかった理由

Git-LFSへの移行(変換)を調べているとBFGを使った移行方法の説明が多く見つかります。

AttlasianGitlab.comBFGを使用した移行ドキュメントを公開しています。

ところが、ドキュメント通りにBFGによるGit-LFSを実行したところ、一見問題なく移行できたように見えて、実はうまくいってないのでは? という状態になり、色々調べ直したところ、現在は git lfs migrate で問題なく移行できるというところに行きつきました。*2

BFGでのGit LFS移行について、自分の環境で問題になったのは以下の点です。

  1. BFGが生成する .gitattributes ファイルはオプションで指定した文字列がそのまま入ってしまう関係上、Git-LFS的に無効なフォーマットで生成される場合がある。(これにより、問題なくgit lfs pullできるが、git lfs管理のファイルがModifiedな状態として認識される事態が発生した)*3
  2. .gitattributes ファイルが、ルートになるディレクトリだけでなく、対象となるファイルがあるフォルダ毎に生成されてしまう。*4(1.の問題に引っかかると認識しにくいが、リポジトリ内を一括で変換してるのにディレクトリ毎に .gitattributes ファイルを管理することになるのはうれしくなかった)

1. Bitbucket Cloud から --mirrorでクローン

git clone --mirror git@bitbucket.org:[ユーザー名]/[リポジトリ名].git

※クローンした [リポジトリ名].git を別にコピーしておくなり圧縮して置いておくなりすると、繰り返しテストする時など大変便利がいい。

2. git lfs migrate info による事前調査

クローンした[リポジトリ名].gitフォルダに移動したのち、現在の状態を調査

git lfs migrate info --everything

上記を実行すると、リポジトリに含まれるファイルのサイズを拡張子毎に集計して、容量降順に並べて表示してくれる。 デフォルトだとトップ5の拡張子まで表示してくれる。

--everything は全ブランチを対象にするオプション。

git lfs migrate info --top=20 --everything

だと、トップ20まで表示してくれる。

あくまでも拡張子毎に集計しているだけなので、.csなども普通に入ってくる。

参考にしつつ、対象となる拡張子(またはファイル)を選定する。

なお、このgit lfs migrate infoでは拡張子の大文字小文字も厳密に分けて集計される。 これはのちに実行する変換コマンドでの指定でも同様なので留意する。

バイナリだからとにかくGit-LFSに移行すればよいってものでもないと思うので、そこの判断は慎重に行う。(あとマイナー?な拡張子はバイナリかどうかの判断に困ったりもする)

3. git lfs migrate import 実行

[リポジトリ名].gitフォルダ内で、Git LFSに移行するファイルを指定してgit lfs migrate importコマンドを実行する。

git lfs migrate import --include="[Git LFSに移行するファイルの指定]" --everything

--include でのファイル指定はワイルドカード(*)が使えるので、拡張子を指定する場合は *.[拡張子] で指定する。複数指定がある場合はカンマ(,) でつなげていく。

例として、以下の指定だと、拡張子wav,png,bmp,zipのファイルが移行対象になる。

git lfs migrate import --include="*.wav,*.png,*.bmp,*.zip" --everything

※細かい指定方法などは git-lfs/git-lfs-migrate.1.ronn at master · git-lfs/git-lfs · GitHub を参照のこと。

あまり指定が長くなるようなら、(Git Bashなので) \ でつないで複数行にする。

git lfs migrate import の実行が完了したら、以下のコマンドで、ローカルのファイル・キャッシュを整理する。*5

git reflog expire --expire-unreachable=now --all && git gc --prune=now

リポジトリのルートディレクトリに .gitattributes が追加されているので、--inlude で指定したファイル名、パターンが問題なく記述されていることを確認する。(履歴も改変されて.gitattributesが最初期にコミットされたことになっているはず)

また、git lfs migrate import 実行後に git lfs migrate info を実行すると再度集計できる。この時Git-LFSに移行したファイルはポインタファイルでの集計になっている。これは移行の確認や効果の見直しなどに使う。

4. Gitlab.com へ --mirror でプッシュ

Gitlab.comで新しく作ったGitリポジトリへプッシュ

git push --mirror https://gitlab.com/[ユーザー名]/[リポジトリ名].git

既になにかしらあるリポジトリへも --mirror だとforce扱いでpushできるが、それは結構な荒療治なので諸々確認が必要になる。 (なので新しいリポジトリにpushして移行する形にしている)

リポジトリURI形式がBitbucket CloudとGitlab.comで異なるのはたまたま作業していてそうなっただけで特に意味はありません。

5. 参考資料ほか

github.com

tech.griphone.co.jp

qiita.com

Bitbucket CloudのMercurial(Hg)リポジトリをGitリポジトリに移行したときのメモ

 Bitbucket CloudのMercurial(Hg)サポート終了、そして最終的にはHgリポジトリは削除されるということで、Btibucket CloudのGitに変換・移行した手順のメモです。

bitbucket.org

 当初は、ほならサクッと変換してパパっと移行して終わり! と思っていたところ、いざHgからGitに変換・移行方法を色々調べてみると、あっ、これ存外に面倒くさいな? という感覚を得たので、移行しながら書いたメモを残しておきます。

作業環境: Windows 10 + TortoiseHG + HgGit + Convert Extension のPCで作業

 HgGitは本来Hgコマンド群でリモートのGitリポジトリを管理運用するツールですが、今回はGitリポジトリへの移行のためだけに使用します。そのため、移行したリモートGitリポジトリをHgGitで管理し続けていくという場合には本稿の手順だけでは不十分かと思います。

1. Bitbucket CloudのhgリポジトリをローカルにCloneする

 Clone完了後は失敗時のリカバリやオリジナル保全のため、ローカルでhgリポジトリを触る前に、Clone直後の状態を圧縮するなりコピーするなりしてとっておく。(HgGitの影響で何かしら操作すると.hg内にGit用ファイルが生成されたりもする)

2. コミットログのauthor名を変換(統一)する*1

 特に古いリポジトリなどでPC移行や表記ゆれなどがあり、コミット時のauthor名が統一されていないものがあった。

 移行を機にauthor名を統一することにして、Convert Extensionでリポジトリを変換を利用する。

 今回は今現在GitHubで使っているauthor名に統一した。(将来もしGitHubに持っていくとなったときに便利なので)

 author名変換リストを作成する。

 一行ごとに

[旧author名]=[新author名]

 と書いたテキストを用意する。

コミットログからauthor名を抽出する

 コマンドプロンプトで各リポジトリディレクトリに移動して、hgログ出力からauthor名表記の行を抽出する。

hg log | findstr "ユーザ:"

※hgが日本語設定になっていたので"ユーザ:"表記で抽出、英語だとおそらく"user:"

 Windows cmd標準でuniq的なコマンドが無いので*2、出力を目視確認して必要なものをauthor変換リストに記載する。

 バッチファイルを作って必要なリポジトリのhg log全部叩いたのをユニーク抽出して一発でauthor変換リストを作るやり方もあるなと思ったけれど、今回はそこまでやらなくてもいいかなという規模だったので、コンバートするリポジトリごとに実行して、適宜author変換リストに追記した。(最終的には12種あったauthor名を1つに集約)

 変換するリポジトリの一つ上のディレクトリから、author変更のリポジトリ変換を実行

hg convert --authormap [author変換ファイル] [変換元リポジトリ名] [変換後リポジトリ名]

--authorもあるが、現在は非推奨らしい

 変換後リポジトリは自動に生成されるので、フォルダなどは事前に作らず、変換元リポジトリ名-converted とした。(※指定していない場合は -hg が付いたものが生成される)

 変換後すぐは.hgしか存在していないので、updateで最新のファイル状態に復帰させて諸々確認する。

hg update

 author名が統一できておらず、author名変換の対象になったBitbucket Cloud hgリポジトリは15個中11個だった。(非公開設定のものを含む)

3. gitのbranchとしてhgのbookmarkを適宜作成する

 基本的にはhgのbranchを使って運用していたリポジトリにのみ実施する。

 hgとgitでbranchの概念や扱いが異なっており、HgGitにおいてはbookmarkがgitのbranchに対応する。

 hgリポジトリのbranchを確認

hg branches -c

※-cオプションで閉じたブランチも確認

 必要に応じてブランチに対応するブックマークを作成する。

 hgのdefaultブランチをGitのmasterブランチに対応させる場合のコマンドは以下の通り。

hg bookmark -r default master

※明示的にGitのbranch(hgのbookmark)を作らなかった場合、Pushはできるが何も見えず容量だけ消費しているGitリポジトリになることがある。今回は15個中2個のリポジトリで発生したが、上記のように明示的にmaster bookmarkを作成してから再度Pushしたところ正常に確認できるようになった。(なので、おまじないとして全リポジトリでとりあえずやっておくというのもありかもしれない)

 特に変名する必要のないブランチは -hg を付けたブックマークを作成(ブランチと同名のブックマークは作成できないため)

hg bookmark -r [ブランチ名] [ブランチ名]-hg

 作成したブックマークを確認

hg bookmarks

 最終的にブランチ移行が必要なhgリポジトリは15個中3個だった(元々ブランチを多数作っていたリポジトリ1個、hg defaultをGit masterに対応させる必要があったもの2個)。

4. Bitbucket Cloudで移行先となるgitリポジトリを作成する

 元となるBitbucket Cloud hgリポジトリ名に -git を付けたリポジトリを作成する。  public/private設定などの各種設定もhgリポジトリに準じたものとした。

 Bitbucket CloudでリポジトリのURLはリポジトリ名がそのまま利用される、リポジトリ名は後で変更が可能なので、公開リポジトリなどで同じURLを維持したい場合は元のhgリポジトリ名を -hg を付けるなどして変更した後に移行したGitリポジトリ名を元のリポジトリ名にするという手段がある。

5. 移行先のBitbucket Cloud GitリポジトリにPushする

 sshの公開鍵認証によるPushになるので、Bitbucket Cloudに公開鍵の登録と、ローカルのsshクライアントへの秘密鍵の登録を済ませておく。

 今回はTortoiseHg付属のPageantを使うので、Pageant秘密鍵を登録して、起動した状態にしておく(閉じていてもタスクトレイにいればいいはず)。

 鍵生成や登録設定については、Atlassianのサポートに記事があるので本稿では割愛する。

confluence.atlassian.com

 Bitbucket Cloud GitにPush

hg push git+ssh://git@bitbucket.org/[ユーザー名]/[Gitリポジトリ名].git

 コマンド完了後にBitbucket CloudのGitリポジトリを確認して終了。あとは置いておくなり、Gitクライアントからいじるなり、リポジトリ名変更までやって移行するなり。

 今回はGitへの移行までなので、これだけ。HgGitのまま使い続けるのであれば、毎回URI書くのは手間なので、 .hg/hgrc に各種パスを記述したりするなどいろいろな設定が必要になるはず。

移行したリポジトリ

 公開リポジトリは長年放置してあるものが多いですが、本手順での移行の参考にどうぞ。

 リポジトリ名末尾に-hgold が付いているリポジトリが移行元になったhgリポジトリです。

bitbucket.org

参考文献など

qiita.com

qiita.com

stackoverflow.com

www.proton.jp

mochi-ha.hatenablog.com

www.google.com

www.mercurial-scm.org

bokko.hatenablog.com

confluence.atlassian.com

yymm.bitbucket.io

flying-foozy.hatenablog.com

今回使わなかった移行方法など

  • Bitbucket Cloudでリポジトリ削除するときには移転先URL表示するようにできるので、同名URLにこだわれなければ何かしらで移行した別名リポジトリに飛ばすとかでいいかも(でもオリジナル消すの怖いよな...)
  • GitHub.comのimportツールで移行すると、おおむね問題なさそうだったが、コミットメッセージの日本語が化けてしまったので利用せず
  • Gitlab.comのBitbucket Cloudインポートは今のところgitリポジトリしかインポートできなかった
  • fast-exportは今回の移行方法よりも実行環境を整えるのが面倒そうだったので試さなかった

おわりに

Git移行したんやからでかいリポジトリ(TorqueLリポジトリがほぼ1GB)はGit-LFSに移行したろ! と思ったらこれまた面倒な感じだったので調査と検証中...

*1:コマンドのオプション名からauthor表記にできるだけ統一したけど、ユーザ/userの方がより正しいのかな?

*2:標準コマンドの組み合わせでuniqを実現してる例はある

商標登録6121255号「トルクル」に関して、商標登録異議申立を行いました。

 とりあえず、表題の通りなんですが、結論まとめ3行。

  • 商標登録6121255号「トルクル」第9類 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの)の登録を取り消すよう、特許庁に異議申し立てを行いました。
  • 「TorqueL(トルクル)」の販売・配信について今のところ影響はありません(おそらく今後もないと思われる)
  • 異議申立ての結果がわかるのはだいぶ先です(年内にわかれば早い方)

商標登録6121255号について

 商標登録6121255号「トルクル」は京都機械工具株式会社を権利者として平成30年4月11日に出願、平成31年2月8日に登録、平成31年3月5日に公報されました。

 区分・指定は以下のように登録されています。(強調はこちらで付加したものです)

区分 指定商品・指定役務
7 金属加工機械器具,動力付き手持工具,インパクトレンチ,ナットランナー,電動ドライバー,電動ドリル
8 手動工具,手動利器,トルクレンチ,トルクスクリュードライバー(手動工具)
9 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの),コンピュータプログラム開発用コンピュータプログラム,製造業における生産性向上を支援するためのシステム用コンピュータプログラム,測定機械器具,トルク測定機械器具,トルクゲージ,ノギス,マイクロメーター,タイヤ空気圧計,深さゲージ,距離測定機械器具,ホイールバランサ,気圧計,ゲージ,電気式測定機械器具,試験装置(医療用のものを除く。),電子出版物
37 測定機械器具の修理又は保守,金属加工機械器具の修理又は保守,手動工具の修理又は保守,動力付き手持ち工具の修理又は保守

 商標登録6121255号については、日ごろTwitter上などで「TorqueL(トルクル)」の関連情報を収集しているうちに、2018年4月末ごろに商標登録OCRbotのツイートをきっかけに出願に気づき、以来その経過を見守ってきました。

 商標登録6121255号の全情報については以下の固定URLから参照してください。(以下のURLからさらに先のURLについては共有してもうまくいかないことがあります)

https://www.j-platpat.inpit.go.jp/web/TR/JP4_2018045392/425224C7CE0E1A98AB6A0213CCD6D9EB

異議申立手続きについて

 当方は商標法第4条第1項第10号(商標法第43条の2第1号)に基づき、「トルクル」は指定区分・指定役務「第9類 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの)」について未登録の周知商標であるとして、商標登録異議申立手続き*1をとることとし、特許庁に商標登録異議申立書を提出しました。

 商標登録6121255号の権利者である京都機械工具株式会社については、スマートセンシングデバイス「TORQULE(トルクル)」を実際に商品展開しており、商標のフリーライドなどには当たらず、また拙作「TorqueL(トルクル)」とは(商標上の)商品・役務などもかぶっていないものと考えていますが、おそらくスマホアプリなどの展開のために補助的に申請されたと思われる「第9類 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの)」に限っては、拙作との権利衝突の可能性がある(または商標権の行使により拙作へ影響を与えることが可能である)と考えております。

 商標登録6121255号の登録にあたり、京都機械工具株式会社から連絡等のコミュニケーションはこれまでありませんし、先に書いたように商品・役務として直接衝突するものではないと思われるため、当方は京都機械工具株式会社と事を構える気もなく、あくまでも特許庁の判断に異議を申し立てるものです。

 そのため、今回の異議申立が認められれず、当該商標の異議申立範囲での取り消しが行われなかった場合においても、先使用権の主張のための法的手続き、当該商標の無効審判手続きなどは(もっぱら手続きにかかる手間暇の問題からではありますが)行わないつもりです。

 商標登録異議申立の審理については、商標登録異議期間と(その間に提出されたものの)補正期間が終了してから、6か月から8か月程度と案内されている(PDF)ため、年内に結果が出れば早い方だと思います。

 なお、「第9類 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの)」が「TorqueL(トルクル)」のようなゲームソフトウェアを含むかどうかについては当方は判断がつかず、念のため異議申立てを行っているという面もあることも付記します。(類似群コードだけでは判断が難しく、家庭用ゲームソフト・業務用ゲームソフトなどは別に区分や役務が設定されていることがあるため)

 ですので、異議申立てそのものが通らなくても、「第9類 コンピュータプログラム(記憶されたもの又はダウンロード可能なもの)」が「TorqueL(トルクル)」のようなゲームソフトウェアまで及ばないことが確認できれば重畳だと考えています。

 記事の最後に今回の商標登録異議申立書と参考にした色々なURLを貼っておきます。

留意事項

 今回の異議申し立てにあたって「未登録の周知商標(商標法第4条第1項第10号)」を申立て理由に挙げていますが、周知かどうかの判断は当該商標の出願日時点(あるいはそれ以前)で判断されます。そのため、今から広めようというようなことは(ありがたいことではあるのですが)、異議申し立てには影響しません。

 「需要者の間に広く認識・周知されている」の「需要者」とは、いわゆる一般の消費者だけでなく、取引先なども含みます。

 「TorqueL(トルクル)」は2014年12月24日より前に各種イベントでの展示や、賞をいただいたことなどもありますが、今回の異議申し立てにあたっては「業として」の判断が容易である2014年12月24日以降の情報を証拠として使用しています。(甲第23号証は許諾周りのやり取りが2014年12月24日以降に行われているため例外的に使用しています)

商標登録異議申立書(一部公開用に修正入り)

f:id:nanmo:20190311213959j:plain
p.1

f:id:nanmo:20190311214026j:plain
p.2

f:id:nanmo:20190311214047j:plain
p.3

f:id:nanmo:20190311214104j:plain
p.4

f:id:nanmo:20190311214127j:plain
p.5

f:id:nanmo:20190311214143j:plain
p.6

参考URL

出願しても登録にならない商標 | 経済産業省 特許庁

商標登録異議の申立て | 経済産業省 特許庁

郵送等で手続する方へ | 経済産業省 特許庁

類似商品・役務審査基準〔国際分類第11-2018版対応〕 | 経済産業省 特許庁

「鳥貴族」と「鳥二郎」【異議申立】

www.astermarks.jp

www.ishioroshi.com

imaokapat.biz

speakerdeck.com

2019.04.26追記

今回の異議申し立ては 異議番号 2019-900082 で通知されています。

*1:本当は審議中に情報提供するのが良かったのですが、情報提供出来ることに気が付いたのが商標登録異議申立書を本格的に仕上げようとしてからでした

【追記あり】VRMとVRoid Hub登録とライセンスとか

と、ライセンス周りを調べて何となく図にまとまったので、はてなブログにも残しておくテスト。

f:id:nanmo:20190109121802p:plain

[ここから追記: 2019/02/07]

VRoid HubのFAQでライセンス周りの説明がアップされていたので、確認もしつつ再検証しました。

(ツイート張り付けてますが、ちょっと見づらいかもしれません)

ということで、「アップロードする際、自動的に~書き換わる」は誤った表現でした。申し訳ございません。

このツイートのあと数日して、ピクシブさん(VRoid Hub)からサポート問い合わせの返信がありまして、ライセンスの非互換性などの諸問題については把握していただけているようです。

トルクル一斉セールやるます。

突然ですが、10月1日から31日まで、収益の一部を北海道への募金に充てる、トルクル一斉セールを実施いたします。

セールの詳細は下記ツイートや、そのリンク先であるSteam Communityのニュースでご確認ください。

「ニコニコチャンネル、20chの配信者が1億円越えの収入。有料登録者は70万人突破」のわからない数字を計算した

以下の記事を見かけて、

av.watch.impress.co.jp

読んだら累計収益受取額のグラフが、「累計収益受取額100万円以上のチャンネル」に絞ったグラフだったので、有料チャンネル数とかは出てるけどグラフに該当するチャンネル数がわからんなあと思って計算したメモです。*1

  • 有料チャンネル総数(x)=1,303
  • グラフに使っている「累計収益受取額が100万円以上のチャンネル数(a)」が不明なので求めてみる
  • 「1,000万を超えるチャンネル(b)」は200チャンネルに「迫る」 -> (b)=200と「多く」仮定してみる
  • (a)のグラフのうち(b)の割合は31.6% ->
    • (a) * 0.316 = 200
    • (a) = 200 / 0.316 = 632.911392.... = 633(四捨五入した)
    • 「累計収益受取額100万未満のチャンネル(c)」 = (x) - (a) = 670

(b)は「200チャンネルに迫る」を200と「多く」仮定しているので、(a)は「多く見積もって」633、(c)は「少なくとも」670と見積もれる

ひとまずまとめ

有料チャンネル数(x) 1,303 のうち、

累計収益受取額100万以上のチャンネル(a)は「多く見積もって」 633

累計収益受取額100万未満のチャンネル(c)は「少なくとも」 670

少しだけ続けて、
  • 累計収益受取額「約20チャンネルが1億円を突破」
  • (a)のグラフのうち1億円以上は 3.2%

先に求めた「多く見積もった」 (a) を使って計算してみる

(a) * 0.032 = 20.256

「多く見積もった」 (a) は「約20チャンネルが1億円を突破」と矛盾はしない

おわり

*1:あとは5年で有料会員10倍といわれても1年ごとの成長率でみるとうーんとか、1000万以上と100万以上にピークがあって間が少な目でうーんと思わないこともない

pixiv FANBOX をはじめ(てみ)ました

5月の頭あたりからpixiv FANBOXのページを作って運用してみています。

www.pixiv.net

こういったサービスはクリエイターのパトロン的なベーシックインカムの側面を押し出していることが多いように思うんですが、 どうもそう考えるとうまく腹落ちしなかったので、旧作の同人誌(?)をいつでも見られるサブスクリプションの体で支援特典を設定しました。

www.pixiv.net

ゲームのダウンロード版を支援特典にすることも考えましたが、設定できるのは単純はファイルのダウンロードなので、ちと難しいかなと思っています。

諸々どうなるかなと思いつつ、少なくとも年内いっぱいぐらいはぼちぼち更新するつもりです。

内容としてはあまり込み入ったテキストの修飾などはできないようなので、各種公式サイトとはてなブログの間ぐらいの立ち位置になるかと思います。

www.pixiv.net

www.pixiv.net

基本地味な更新が続くと思いますが、よろしくお願いします。