Update source code.
# git svn fetch
# git svn rebase

git 不能用 bare 當作 svn 的 repository. 只能用 work repository
所以如果有其他目錄 clone 出去要 commit 進來時, 可以用這個指令

# git push origin master:origin
將自己的 master 推到 remote 的 origin 去, 有時候 origin 存在時無法 push, 就換另一個名字再 push.

# git push origin master:origin3

然後在原來的 repository 應該就可以 commit 了
# git svn dcommit

如果沒有辦法, 可以切到 master
# git checkout master
再下 cherry-pick (只上 patch), 如果什麼都不下, 就是只上一個 patch
# git cherry-pick origin
如果要上很多 patch
# git cherry-pick start_patch^..end_patch
這邊要用 start_patch 的前一版, 我也不知道為什麼啦.

如果一次改了很多 bug 要分別 patch
可以用
# git add -p
這時候就會一個 diff 一個 diff 列, 命令列還有 s (split), e(edit) 可以將 diff 分成兩個和修改.

做完之後
# git diff –cached
看己經儲存的 patch
# git commit
不能用 -a , 這樣會連其他的一起 commit

commit 錯了
# git reset HEAD^
可以重新 commit 一次
清除 code.
# git reset –hard
如果只是打錯 commit 的說明
# git commit –amend

其他太複雜的就暫時不研究了.

The post git subversion appeared first on richliu's blog.

這時可以產生另一個 bare 目錄, 然後到 git 目錄內下指令, 將該目錄變成 bare
[BASH]
# cp -a (path_to_source_dir) (path_to_bare_dir)
# cd (path_to_bare_dir)
# git config –bool core.bare true
# rm (all source code)
# mv .git/* .
# rmdir .git
[/BASH]

這樣就可以了.

原來的目錄可以修改 remote url 的方式指到新的目錄
[BASH]
# cd (path_to_source_dir)
# git remote set-url origin //(path_to_bare_dir)
[/BASH]

這時有 source code 的目錄還是用 git push/pull 更新 source code.
如果是 bare 的話就是 git push, git fetch/merge 更新 source code.

Ref web.
http://stackoverflow.com/questions/2816369/git-push-error-remote-rejected-master-master-branch-is-currently-checked
http://stackoverflow.com/questions/2432764/how-to-change-a-remote-repository-uri-using-git

The post [GIT] 將現有的目錄改成 bare 並且修改 remote server appeared first on richliu's blog.

假設主要的 tracking branch name 是 major. (一般用 origin or master, btw, 我是從別的地方再 clone 過來的, 所以不用此名)
創立一個新的空 git 目錄.
[BASH]
$ cd /data/prj/AMP/core-data
$ git init –bare
[/BASH]

在 source code A 下, 建立一個新的 remote
[BASH]
$ git remote add test /data/prj/AMP/core-data
$ git push test major
[/BASH]

在 source code B 下, 加入一個新的 remote, 用 git reset –hard 是清除所有的改變, 以便 pull
[BASH]
$ git diff
$ git reset –hard
$ git remote add test /data/prj/AMP/core-data/bare/
$ git pull test major
[/BASH]

* 若是遇到這種情形, 可以檢查是不是這個檔在是 untracked, 可以用 $ git status 查看. 如果是 untracked, 可以刪除.
[BASH]
$ git pull test major
From /data/prj/AMP/core-data/bare
* branch major -> FETCH_HEAD
error: Untracked working tree file ‘kernels/linux-2.6.35.12/arch/arm/kernel/real-amp.c’ would be overwritten by merge. Aborting
[/BASH]

git 功能太多 :-/

The post git 筆記: 如何將現有的 Tree 推到 remote appeared first on richliu's blog.

因為我 git 的各項操作實在是太慢了.
慢到整個系統大概可以和 P5 比吧 (反正就是慢慢慢)

一開始我以為是 raid/disk 的問題, 不過在數次交叉測試下, 看起來兇手指向 File System
以下就是我的測試環境.

CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
OS: Ubuntu Linux 10.04 LTS
HDD1: Device Model: Seagate ST31000528AS (1T)
HDD2: Device Model: Seagate ST31000528AS (1T)
同一顆.

測試方式.

HDD1, HDD2 分別切了 40G 的 Primary 1 Partition.
第一次在 HDD1 測 ext4 , HDD2 測 xfs
第二次在 HDD1 測 xfs , HDD2 測 ext3
第二次測完後追加 ext3 和 btrfs
使用 time command 測試時間.
在 Copy 之前會先 mkfs disk .
硬碟內先行準備好一個 git repository 的測試資料, 然後再另建一個目錄 clone 這份測試資料(不細測 Read/Write)

測試資料.
9.1G 的 .git source tree. 包含 5G 的 .git database 還有 4.1G 的 source code/binary/image .. 等等資料. 約有 2800 個 commit.

以下是測試數據
First Round
sda1: ext4
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 3m30.381s
user 0m24.878s
sys 0m31.402s

sdb1: xfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 13m47.297s
user 0m31.510s
sys 0m24.482s

Round 2:
sda1: xfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 13m10.405s
user 0m32.122s
sys 0m19.761s

sdb1: ext4
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 1m25.192s
user 0m26.210s
sys 0m14.017s

sdb: ext3
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk2/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 3m5.792s
user 0m25.534s
sys 0m23.065s

sda: btrfs
# time git clone ../trunk/
Initialized empty Git repository in /mnt/disk/1/trunk/.git/
Checking out files: 100% (216892/216892), done.

real 1m13.981s
user 0m24.670s
sys 0m32.730s

簡單的做一個圖表做測試結果.

由此圖可知, 我的效能問題是出在 xfs 上.將 raid system 改成 ext4 後, 這個問題就解決了.

但是奇怪的是, xfs 雖然花了 13m, 但是實際 CPU 使用時間並不多. 這個問題也有可能是 ubuntu/Linux kernel 造成的.

ext4 和  btrfs 都各有一次不錯的表現. 尤其是 btrfs, 才 1m13 秒. 大家有常常使用 git 的, 可以考慮一下 btrfs.

受限於個人時間, 這個測試並不嚴謹, 不過己經可以解決我目前的問題, 至於這個數據, 簡單整理一下以後, 可以給常常使用 git 的朋友一個參考的資料.
接下來就是希望有人能夠花點時間做出更完整的數據, 或是順便 Debug 了.

The post git 和 filesystem 的 Performance appeared first on richliu's blog.

解決方案是在 repack 時, 在 memory scale 使用較小的 memory
這樣就不會因為 small object 太多, 太快吃掉所有的 memory .

語法
[BASH]
$ git repack -adf –window=memory
[/BASH]

跑完一次 repack 之後, 接下來就可以正常跑 GC 了.
以下是我的 Log
[BASH]
root@rl-desktop:/data/git-pool/vega-base/trunk# git gc
Counting objects: 174589, done.
Delta compression using up to 4 threads.
fatal: Out of memory, malloc failed09843)
error: failed to run repack
root@rl-desktop:/data/git-pool/vega-base/trunk# git repack -adf –window=5
Counting objects: 174589, done.
Delta compression using up to 4 threads.
warning: suboptimal pack – out of memory)
fatal: Out of memory, malloc failed69814)
root@rl-desktop:/data/git-pool/vega-base/trunk# git repack -adf –window=2
Counting objects: 174589, done.
Delta compression using up to 4 threads.
fatal: Out of memory, malloc failed69814)
root@rl-desktop:/data/git-pool/vega-base/trunk# git repack -adf –window=1
Counting objects: 174589, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (169814/169814), done.
Writing objects: 100% (174589/174589), done.
Total 174589 (delta 77228), reused 0 (delta 0)
root@rl-desktop:/data/git-pool/vega-base/trunk# git gc
Counting objects: 174589, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (92586/92586), done.
Writing objects: 100% (174589/174589), done.
Total 174589 (delta 77228), reused 174589 (delta 77228)
root@rl-desktop:/data/git-pool/vega-base/trunk#
[/BASH]

The post git gc: Out of memory, malloc failed appeared first on richliu's blog.