Gitサイズが大きいレポジトリのクローンエラー①

Gitサイズが大きいときのクローンでは、エラーが発生することがある。


remote: Counting objects: 13751, done.
remote: Compressing objects:  78% (2213error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

git did not exit cleanly (exit code 128) (2403 ms @ 2016/01/18 18:39:49)


その場合、以下のように、depth=1で1回Cloneしたあと、Fetchすると取得できるようだ。
以下のコマンドでもできるが、トータスGitなどを使えば、 GUIからも可能。


コマンド例
git clone --depth 1 http://hoge.com/hoge.git
git fetch --depth 5
git fetch --depth 20
git fetch --unshallow


また、サーバ側での設定を変えることで対応することもできる。

サーバ側のConfigファイルに以下の設定をする。
(pack配下だけでいいかも。値はサーバに応じて設定）

[core]
    packedGitLimit = 4000m
    packedGitWindowSize = 1000m
[pack]
    windowMemory = 4000m
    SizeLimit = 4000m
    threads = 1
    window = 0

EGitで競合を解決する

コミットで競合が発生した場合、マージ作業をおこなわなければいけないのは
他のソース管理と同じだが、
EGitでは、マージを修正完了したファイルを自ら『索引に追加』をおこなうことで
競合を解決したことを認識させる必要があるようだ。

Gitサイズが大きいレポジトリのクローンエラー②

EGitでいつものように、クローンをしようとしたら、意味深なメッセージが出た。

aborting due to possible repository corruption on the remote side

ネットを検索すると、Gitのデータが破損している可能性があるとかなんとか・・・
また、面倒くさいことになったなと思いながら、
ふと思いついた。

サーバーのメモリーが足りていないのでは？

ＳＳＨでログインして、freeをすると、
案の定、８Ｇの物理メモリを７.５Ｇ以上も使用中ではないか!!!

rebootして、再度クローン。
調子よく動いているとおもっていたら、今度は
なにやらタイムアウトメッセージが・・・

ウィンドウ設定で
チーム＝＞Ｇｉｔ＝＞リモート接続タイムアウトを500秒にしてもう一度実行。

今度は、問題なくいけた。
面倒なことにならなくてよかった、よかった。

EGitでのRevertでコミットを戻す

EGitで、Revertするとどうなるのかメモ。

EGitで、Gitのヒストリーを表示して、一覧のどれかを右クリックすると
Revertメニュー（コミットを戻す）が表示される。

これをおこなうと、一覧で選択しているコミットを打ち消すためのコミットが作成されるようだ。
それ以外のコミットには、影響しない。
一覧で選択しているコミット時点まで戻るということではないので注意。

＜手順詳細＞
①プロジェクト全体を指定して、チーム＝＞ヒストリーを表示。
②ヒストリーの一覧から、戻したいコミットを選択して右クリック
　（ここで選択したコミットだけが削除される）
③コミットを戻すをクリックする
④②で選択したコミットだけを戻すための打ち消し用コミットができる。
⑤この状態でPUSHすれば、サーバ側にも反映される。

☆コミットを戻すの実際☆
実際には、「コミットを戻す」というのは、そのコミットを打ち消すソースを自動生成してくれるものの
そのコミット以降のコミットは考慮してくれないので、競合が発生しマージ作業が発生してしまうのがおちだと思う。
マージ作業は、ミスをすれば他の人の修正を消してしまうこともあるだろうし、意外と神経を使う作業なのでできればやりたくないのがプログラマの本音。

つまり、変更する箇所が明確にわかっているのであれば、この機能を使うよりも、自分の記憶を頼りに最新バージョンに対して修正をおこなったほうが、効率的であるし確実であると思う。

SVNからGitに乗り換えたときに初めて聞くであろう用語

SVNからGitに乗り換えたときに、知らない用語がたくさん出てくる。
そんな用語をここで、まとめておく。


■clone (クローン)
クローンとは、SVNでのチェックアウトとほぼ同じ意味。
簡単に言えば、リポジトリから、ローカルにファイルを落としてくること。

ちなみに、Gitでのチェックアウトは、SVNの意味と違うので注意が必要。
Gitでのチェックアウトとは、作業ブランチを切り替える（決定する）意味。
devブランチからmasterブランチに切り替えるとき、masterブランチをチェックアウトするという。


■push (プッシュ)
リモートのリポジトリへ反映すること。
Gitでは、ローカルにリポジトリをもつので、コミットとはローカルのリポジトリに反映することとなり、その状態では、サーバーに反映されていない。
プッシュして、はじめてリモートに反映されることとなる。
ここがSVNとの大きな違いといえる。


■pull (プル)
プル＝コミット＋プッシュの反対。
プル＝フェッチ＋マージ
サーバリポジトリからローカルリポジトリにデータを取得し（これをフェッチという）、さらに作業ブランチへも反映する。（これをマージという）

[注]プルは使うなという人もいるように、実は奥が深いのがこのコマンド。
リスク回避のためには、フェッチしてマージするほうがベターのよう。


■fetch (フェッチ)
プルでおこなわれるうちの最初のほう。
サーバリポジトリからローカルリポジトリにデータを取得するまでをフェッチという。


■merge (マージ)
プルでおこなわれるうちの後のほう。
ローカルリポジトリから作業ブランチへ反映するまでをマージという。
コンフリクトが発生する場合もあるので、手動マージをおこなうなどで対処する。


■HEAD
対象のブランチの先頭のこと。
つまり、最新コミットのこと。
HEADと一言で言っても、どのブランチのHEADなのかを意識しないと危険。
（ブランチがリモートなのかローカルなのかmasterなのかdevなのかなど。）


■origin
リモートをあらわす意味で使われることが多い。


■fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがないため、コンフリクトなしにそのままマージできること。
細かい話でいうと、HEADの書き換えだけでマージができてしまう状態のこと。

ex.
masterブランチからdevブランチを作成したあと、devブランチでコミットを１回した。
masterでは、コミットされていない。
この状態で、devブランチをmasterブランチにマージしたとき、コンフリクトなしでマージできるので、これをfast forwardという。


■non fast forward
ブランチ元のブランチへマージしようとしたとき、ブランチ元で新たなコミットがあるとき、non fast forwardという。
要は、コンフリクト（競合）しているということ。
そのまま、マージせず、手動マージするなどの対応をするのが普通。


■rebase (リベース)
一度分岐したブランチをマージするときに、分岐した歴史を消すこと
そのブランチでのコミットがあたかも、マスター上（マージ後ブランチ）でコミットされたようになる。
リベース後は、２つの枝だった状態がマスタ（マージ後ブランチ）だけの１つの枝になる。


■cherry-pick (チェリーピック)
あるブランチ上の特定のコミットだけをマスター（他のブランチ）に反映するコマンド。
リベースがブランチ上のすべてのコミットを対象にするのに対し、こちらは特定のコミットだけを対象とする。


■stash (スタッシュ）
作業の途中で、他のブランチに切り替えるときに、作業状態を記憶しておくこと。
stashにプッシュするとかいう。
Gitの場合、これをせずに、ブランチを切り替えると、コミットしていないものとかは消えてしまうので注意が必要。

再び、もとのブランチに戻ってきたときに、プッシュしたものをポップすると元の作業状態に戻すことができる。

保存したブランチと違うブランチでポップする（元に戻す）と、ブランチ違いでも適用されてしまうので注意が必要。

複数stashできて、呼び戻すときも対象のものを選ぶことができる。
stash saveするときに、メッセージもつけれる。

EGitでは、チームメニューおよびGitRepogitoriesパースペクティブでできるよう
stash changeメニューやStashリストから適用、削除を実行する感じ
http://wiki.eclipse.org/EGit/New_and_Noteworthy/2.0