[Linux] git 사용 시 Proxy 환경 아래서 https 인증이 제대로 안될 때

git 사용 시 Proxy 환경 아래서 https 인증이 제대로 안될 때 다음과 같은 에러 발생 시..

error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://주소.com/프로젝트.git/info/refs
fatal: HTTP request failed


아래처럼 하고 해보자.
 

$ export GIT_SSL_NO_VERIFY=true

우아한 방법은 아니지만 동작은 한다.
다음처럼 설정도 가능.

$ git config –global http.sslVerify false

참고 :  http://stackoverflow.com/questions/3777075/https-github-access

[git] 어떤 commit 이 어느 브랜치에 있는지 확인하고 싶을 때

tag로 checkout을 한다던가 하게되면 이게 지금 어느 브랜치에서 나온건지를 알 수 없을 때가 있다. 또는 어느 commit 이 어느 브랜치 상에 있는지를 알고 싶을 때 라던가.. 이럴 때 사용할 수 있는 것이
git-what-branch 스크립트다.

https://github.com/SethRobertson/git-what-branch  

$ git-what-branch –allref <commit sha1 id>

 

gerrit 프로젝트 Mirroring 하기

gerrit을 사용하면 자기가 access 권한이 있는 프로젝트의 리스트를 ssh를 이용하여 ls-projects 라는 명령을 이용해서 얻어올 수 있다. http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.0/cmd-ls-projects.html 를 참고하면 되는데, 해당 도움말을 보면 이 명령을 이용해서 접근 가능한 모든 Project 를 clone 할 수 있는 쉘 스크립트가 있다.

for p in `ssh -p 29418 review.example.com gerrit ls-projects`
do
  mkdir -p `dirname "$p"`
  git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git" 

done 

이것과 crontab, shell script를 조금 응용하면 계속적으로 업데이트 함으로써 Mirroring 을 할 수 있다.

#!/bin/sh
PLATFORM_HOME=`readlink -e .`
PROJECT_LIST=`ssh -p 29418 review.example.com gerrit ls-projects`
ROOT=”ssh://review.example.com”
DIRNAME=”/usr/bin/dirname”
BASENAME=”/usr/bin/basename”
for PROJECT in $PROJECT_LIST
do
        cd $PLATFORM_HOME;
        echo “——————————————————–“
        echo ” $PROJECT.git”
        if [ -d $PROJECT.git ]; then
                echo “Entering $PROJECT.git”;
                cd $PROJECT.git;
                git remote update
        else
                echo “Cloning $ROOT/$PROJECT.git”;
                PROJECT_DIR=`$DIRNAME $PROJECT`
                mkdir -p $PROJECT_DIR
                git clone –mirror “$ROOT/$PROJECT.git” “$PROJECT.git”
        fi
done

 미러링 사용시에는 받아오기 전에 다음 명령과 같이 설정하여 사용하면 된다.

 git config –global url.”git://<IP>”.insteadOf “git://codeaurora.org”

git/gerrit 사용시 알아야 할 것

git과 gerrit 을 사용할 때 최소한 알아야 하는 것을 정리한 것으로 회사 내의 git 교육 담당자에게 교육 시 필요한 내용을 정리해서 보낸 내용이다. 이거 다 알면 git 잘 쓴다^^
이것을 차례로 삼아 세부 내용을 하나씩 문서로 만들어 정리하자.

추가1: 이미 http://namhyung.springnote.com/pages/3132772 에 git 사용자 설명서가 있다. 저 namhyung님이 내가 아는 우분투 쪽 김남형 님일까 ㅎㅎ

추가2: http://git-scm.com/book/ko 번역자에게 축복을…

* git
1. Git의 Repository 개념과 clone 의 개념, clone

2. Git의 remote branch와 local branch 간 차이, fetch
3. Remote 브랜치로부터 local branch 를 최신으로 업데이트 하는 방법, pull/rebase의 이해
4. 수정 반영 방법, Git의 Staging area 개념과 작업 방법, add/commit 의 이해, commit -s 옵션
5. Commit 을 수정하는 방법, commit –amend 의 이해
6. Push 방법 – Gerrit의 refs/for/* 개념 이해, push의 이해, push 시의 refs spec 이해
7. Log를 확인하는 방법, log
8. Commit 간 차이(diff)를 확인하는 방법, diff
9. 특정 시점의 소스로 돌아가는 방법, reset
10. 특정 소스 파일을 특정 시점으로 되돌리는 방법, checkout
11. Backout 방법, revert
12. local 브랜치를 만드는 방법, branch
13. remote 브랜치나 local 브랜치로 local 소스를 만드는 방법, checkout
14. cherry-pick 의 이해, cherry-pick
15. patch 파일 만들기와 패치 적용 방법, , format-patch/am
16. merge 방법 및 merge commit이 무엇인지, merge
17. rebase 나 merge 시의 conflict 해결 방법

* gerrit
1. 그룹의 정의 및 권한 이해
2. Verify 방법 – Verify 의 의미 이해
3. Review 방법 – Inline comments 작성 및 cover message 작성(+ 한글 작성 가능 알림)
4. Gerrit 에서 cherry-pick 하기
5. Gerrit 에서 checkout 하기
6. Gerrit 에서 같은 Change의 Patch set 업데이트 하기
7. Submit 시의 동작 이해

개발 환경 개선 Git + Gerrit + checkpatch + cleanpatch

원래 나한테 좀 맞지 않던 카메라 개발에서 벗어나서 요즘 좀 재밌는 걸 하고 있다.
개발 업무를 살짝 벗어나서 SCM 업무를 하고 있는데, 내가 옳다고 생각하는 방향으로 부서 전체를 바꾸고 있어서 좀 재미나다. 회사 전체를 바꿀 수 있으면 더 재미날 것 같지만, 그건 이후의 일이고..

아무튼 요약하면 구글에서 NexusS 개발을 하면서 썼던 git + gerrit 시스템을 적용하고, 여기에 코딩룰 자동 오류 보고 + 코딩 룰 자동 오류 수정 + 수정본 자동 업로드를 구축 중이다. 여러 가지 것들을 조합해서 만들어 내는 개발환경 개선 작업은 신난다.

1. 기존의 불편한 Centeralized VCS 툴을 벗어나 DVCS를 사용해 여러 브랜치의 Integration 작업의 어려움을 줄이고, 같은 패치를 여러 곳에 적용하기 쉽게 만들고,
2. 코드 리뷰 시스템을 통해 좋은 코드를 함께 말할 수 있는 장을 만들고, 코드 개선을 양지로 끌어내고, 코딩 룰에 대해 생각하게 하고, 코드의 구조에 대해 생각하게 하고, 후배 개발자에게 선배 개발자의 지식을 전달할 수 있는 체계를 만들고,
3. 코딩 룰의 자동 체크를 통해 리뷰어의 노력을 덜 들이게 하고, 개발자의 모든 코드의 코딩룰을 검사하도록 하고, 수정하도록 요구하며,
4. 구조 개선 같은 복잡한 것까지는 아니더라도 체크한 패치가 오류가 있으면 간단한 코딩 룰 등은 자동으로 수정해서 바로 업로드 하여 개발자들의 코딩 룰 등 간단한 수정에 드는 노력을 줄인다.

여기에 기존 시스템(빌드, 배포 등)과의 호환성 유지를 위한 작업까지.. 아직은 사내 모든 부서가 내가 구축하는 것을 따르고 있지는 않기 때문에..

개발 생산성 향상이라는게 말만큼 거창한게 아니다. 개선에 개선을 거듭해 쓸데없는 일을 줄이고 줄여, 더이상 뺄 게 없는 프로세스를 만들어 내는 거다.

위에 것이 어떻게 가능하냐. git + gerrit + jenkins + Linux kernel의 checkpatch.pl, Linux kernel의 cleanpatch + Linux shell의 여러 utility + 손수 제작 스크립트(bash, perl 등)를 조합하면 된다.

딴데도 이렇게 하고 있는 곳이 있을까? 내맘대로 세계 최초라 주장하련다. ㅋㅋㅋㅋ

TI OMAP의 Android 관련 페이지 모음

일단 TI의 오픈소스 git repository는 http://git.omapzoom.org/ 이다.
OMAP의 Android 관련 메인 위키 페이지는 http://omappedia.org/wiki/OMAP_Android_Main 이며, 소스를 얻는 것에 대해서는 http://omappedia.org/wiki/Android_source_code_versions 에 설명되어 있다.
또한 플랫폼 쪽의 manifest.xml 를 관리하기 위한 프로젝트는 git://git.omapzoom.org/platform/omapmanifest.git 으로 보인다.
리눅스 상에서 adb 사용에 관한 문서는 http://omappedia.org/wiki/Adb_over_USB 에서 볼 수 있고, 리눅스 및 윈도우즈 상에서의 adb 사용(Blaze 기준)은 http://omappedia.org/wiki/Support_Tools#ADB_over_USB 에서도 볼 수 있다.
툴체인은 http://omappedia.org/wiki/Android:_Configuring_the_Host_PC#ARM_Cross_Compiler 에서 볼 수 있는 것처럼 Code Sourcery의 툴체인을 권장하며 L27x 등 최신 버전은 2010-q1 이 사용되어야 한다고 쓰여져 있다.
방화벽 아래에서의 작업은 http://omappedia.org/wiki/Support_Tools#Firewalls 에서 해결 방법을 볼 수 있다. 해당 해결 방법은 GIT_PROXY_COMMAND 환경변수를 사용하는 것이 아닌 git의 core.gitproxy 설정을 통해 해결하고 있다. 또한 SSH 의 Proxy 를 .ssh/config 파일에서 설정하는 방법에 대해서도 http://omappedia.org/wiki/Gerrit#SSH_Proxy_Setup: 에 나와 있다. 둘다 corkscrew를 이용한다.

Ducati를 사용하는데 사용되는 Syslink에 대해서는 http://omappedia.org/wiki/Syslink_Project 에서 정보를 얻을 수 있고, 현재 Syslink 3(http://omappedia.org/wiki/Syslink_3)로 이행 중인 듯하다. Syslink3 는 Kernel space에서 수행되는 것들을 User space로 옮겨 Linux kernel 에 upstream이 되기 힘든 단점을 극복하려는 듯 하다.
XDCtools 는 http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/index.html 에서 다운로드 받을 수 있고, CodeGen tool과 BIOS 등 모든 툴은 TI Account가 있어야 다운로드 받을 수 있는 듯 하다.

Ducati 에 대한 정보는 http://omappedia.org/wiki/Ducati_For_Dummies 에서 얻을 수 있는 듯 하다.

[git] Untracked files 및 Deleted files 까지 함께 자동으로 commit 하는 방법

다음과 같이 해도 되지만, 시스템 부하가 많이 간다.
git add .
git commit -a
그래서 다음과 같이 하면 더 빠르게 된다.
git ls-files -o | git update-index –add –stdin
git commit -a

[git] git 설정하기

1. git 설치

sudo apt-get install build-dep git-core git-doc

2. git 구성하기
2.1. username과 email 설정

git config –global user.name “Yang Jeong-Seok”
git config –global user.email “dasomoli@gmail.com

2.2.. git 설정 확인

git config –global –list

2.3.. git color ui 사용

git config –global color.ui “auto”

2.4. 기본 인코딩을 cp949로 바꾸기

git config –global i18n.commitEncoding cp949
git config –global i18n.logOutputEncoding cp949

윈도에서는 LESSCHARSET=latin1 으로 설정해야 로그 메시지를 볼 수 있다.

set LESSCHARSET=latin1

2.5. 기본 에디터를 vim 으로 설정하기

git config –global core.editor “vim”