最近、プライベートでコード書いてません。ryosmsです。

JCROMの更新状況を追っかけていると、某氏の謎の行動が気になったりしてたんですが、案の定ハマってたみたいなので書きます
 

さてさて、JCROMのソースは(手が入っているところは)bitbucketでソースを管理しているので、修正してpull reqを送る (下図のイメージ) 際にはGitHubへpull requestする際のベストプラクティスがほぼそのまま使えます(githubとbitbucketの違いに気をつけるだけ)

simgle_repo


ただし、リポジトリの数が膨大(&AOSPのリポジトリも参照してる)ので、ソースの取得にはrepoを使用します
(ちなみに、2012/08/09時点でのjcrom_jb-master.xmlでは、落としてくるリポジトリの数は約300あります)

repoっていうのは、簡単に言えば「複数のgitリポジトリをまとめて、1つのリポジトリのように扱えるようにしたもの」って認識です(git submoduleとは全然違うので興味がある人はggrks)

repo
  ↑repoのイメージ


で、このrepoが入ってくることで、普通にgit+bitbucket(github)使ってると遭遇しないような問題が発生したりしなかったり

(repoについてはそれだけで1本できそうなネタなんで、どこかで発表したいなとは思ってる... okagitでやるか、合同勉強会にぶち込むか...)



・どのリポジトリをforkしていいかわからない 
よくある勘違い:
「ソース落としてくるんだからわからないってことはないだろう。どれどれ、ソースの落とし方は...っと」

$ repo init -u https://bitbucket.org/sola/jcrom_manifest -m jcrom_jb-master.xml
$ repo sync

「この'jcrom_manifest'ってリポジトリをforkすればいいんだな」
_人人人人人人人人人人人人_
> 馬鹿め!それは残像だ <
 ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
manifestはrepoで落としてくるリポジトリの一覧を書いてあるだけなので、これをforkしても(大体の人には)いいことありません

Q. じゃあ、どれをforkすればいいの?
A. 一番手っ取り早いのは、修正したいソースのあるディレクトリで「git remote -v」

$ git remote -v
sola-android https://bitbucket.org/sola/jcrom_hoge_fuga.git (fetch)
... 

とか出てきたらそれがfork対象のリポジトリ
(remote名がsola-androidじゃなければ、AOSPのリポジトリになると思うのでbitbucketなりgithubなりに新規でリポジトリを作って頑張れ!)

あと、「jcrom_[親ディレクトリ]_[子ディレクトリ]」って命名規則でリポジトリ名をつけてるみたいなのでそれも参考にする
例:jcrom_packages_apps_settingsってリポジトリなら、repo syncすると$SOURCE_DIR/packages/apps/Settingsに展開される


・repo syncでコンフリクトした

だから作業するときはブランチ生やせってあれほど...
kernelを自分でビルドするとコンフリクトしやすいです
rebaseやらなんやら駆使して頑張るなり、あきらめて自分の変更点を捨てるなりお好きにどうぞ


・repo syncで取ってきた最新ソースが自分のリポジトリにpushできない

ブランチ確認しろ(git branch or repo branch)
自分のbitbucketのリポジトリをmyForkって名前でリモート登録してると仮定して、コマンド叩くと
$ git push myFork master
Already up-to-date. 
ってなると思う(masterはfork元に追随するために使ってる想定)
これ、repo syncで取ってきたコードは(no branch)になっちゃうのが原因
なので、repo sync後に最新のコードをmasterブランチに反映してからgit pushをしてやる
ブランチに反映するやり方がわからなかったら、そのリポジトリで
$ git pull sola-android master
やればいいと思うよ!

・その他
「こんなとこもハマりポイントで、回避方法はこうだよ!」っての教えてくれれば追記します。
(もしくは、ハマってるところがあれば分かる範囲で気まぐれに回答します)