좀딱의 또다른 세상

fluidsynth v2.4.7 and git v2.50.1 for OS/2 has been released. OS/2 용 fluidsynth v2.4.7, git v2.50.1 을 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : fluidsynth v2.4.7: https://www.os2.kr/komh/os2factory/#fluidsynth git v2.50.1: https://www.os2.kr/komh/os2factory/#git   Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/  

git v2.42.0 for OS/2 has been released. OS/2 용 git v2.42.0 을 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : http://www.os2.kr/komh/os2factory/#git Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/  

git v2.39.1 for OS/2 has been released. OS/2 용 git v2.39.1 을 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : http://www.os2.kr/komh/os2factory/#git Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/  

git v2.30.0 for OS/2 has been released. OS/2 용 git v2.30.0 을 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : http://www.os2.kr/komh/os2factory/#git Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/  

git v2.22.0 and perl v5.16.0-k2 for OS/2 has been released. OS/2 용 git v2.22.0 과 perl v5.16.0-k2 를 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : git v2.22.0: http://www.os2.kr/komh/os2factory/#git perl v5.16.0-k2: http://www.os2.kr/komh/os2factory/#perl Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/

git v2.13.3 for OS/2 has been released. OS/2 용 git v2.13.3 을 발표하였습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다 : http://hobbes.nmsu.edu/h-search.php?key=git-2.13.3.zip&pushbutton=Search Enjoy Warping !!! Korean OS/2 User Community : http://www.os2.kr/

Various programs and libraries for OS/2 have been released. 다양한 OS/2 용 프로그램과 라이브러리가 공개되었습니다. They can be downloaded from : 다음 링크를 클릭하면 받을 수 있습니다: GNU Bison v3.0.4   Coreutils v8.26   GNU Diffutils v3.5   FAAC v1.28   FAAD2 v2.7.0   Gawk v4.1.4   git v2.11.0   gmp v6.1.2   GnuTLS v3.5.8   gperf v3.1   help2man v1.47.4   itstool v2.0.2   lame v3.99.5-r3   libdvdnav v5.0.3   libdvdread v5.0.3   libgcrypt v1.7.5   libgpg-error v1.26   libogg v1.3.2   libpng v1.6.28   libvorbis v1.3.5   libvpx v1.6.1   GNU M4 v1.4.18   GNU Make v3.81-k1   pdksh v5.2.14-bin-7   perl v5.16.0-k1   sed v4.3   texinfo v6.3   zlib v1.2.11 Enjoy Warping !!! Korean OS/2 User Community : http://www.ecomstation.co.kr

git 를 사용하다보면 merge 후에 merge 내용에 대해서 수정하고 싶을 때가 있다. 물론 merge 이후에 새로운 수정 커밋을 만들어도 괜찮다. 하지만, 수정 커밋을 남기고 싶지 않다면, 이렇게 해 보기 바란다. git 에서 commit 를 수정할 때 가장 유용한 방법은 git rebase -i 이다. 그런데 별다른 옵션없이 git rebase -i 를 수행하면, merge 커밋은 보이지 않고, 개별 커밋이 나타난다. 이래서는 merge 커밋을 수정하기가 어렵다. 이 때 필요한 것이 -p 이다. -p 를 사용하면 merge 커밋이 개별 커밋으로 쪼개지는 대신에 하나의 merge 커밋이 나타난다. 따라서 merge 커밋에 수정하고 싶은 것이 있다면, 새로운 수정 커밋을 작성하고 git rebase -i -p 로 수정 커밋을 merge 커밋에 fixup 또는 squash 하면 된다. 예를 들어, git rebase -i -p 를 했을 때 편집기에 다음과 같이 보인다면, pick 834349f Merge remote-tracking branch 'merge' pick 2c5474b 수정커밋 다음과 같이 변경하고 저장하면 된다. pick 834349f Merge remote-tracking branch 'merge' f 2c5474b 수정커밋 이렇게 하면, 수정커밋이 merge 커밋에 적용된다. 사실 -p 옵션은 merge 커밋을 수정할 때 뿐만 아니라 git rebase 의 다른 기능에도 적용될 수 있으니, 잘 활용하기 바란다.

If you use Qt Creator 2.2.1 and git, you may encounter "You did not checkout a branch" when commiting even if other functions of git are working well. This is because git changed the output style of 'status' command. For example, git 1.7.3.2 prepends '#' to each message line. However, git 1.8.5.2 does not. The ways to avoid this problem are upgrading Qt Creator or downgrading git. Unforunately, however, both are not acceptable solutions. The other way is to patch the sources of Qt Creator and to build your own one. Here is the patch for Qt Creator 2.2.1. Colored By Color Scripter ™ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 diff --git a/src/plugins/git/commitdata.cpp b/src/plugins/git/commitdata.cpp index 6bc2a97..3eb6562 100644 --- a/src/pl...

git 의 가장 강력한 장점 중의 하나는 패치 관리라고 생각한다. 패치를 로컬에서 관리하다가 때로는 업스트림에 보내야 할 때가 있다. 한 번에 통과되면 좋겠지만, 대부분 여러 번의 리뷰를 거쳐서 통과된다. 그런데 매 번 같은 이름으로 패치를 보내게 되면 이전의 패치와 헛갈리는 경우가 종종 있다. 이를 피하기 위해 패치에 판번호를 붙일 필요가 있는데, 이 방법을 살펴보자. 가장 기본적인 방법이라면, format-patch 로 패치를 만들고 나서, 해당 패치 파일들을 수작업으로 수정하는 것이다. 패치 파일이 한 두개라면 상관없지만, 그 이상이면 일일이 바꾸는 게 쉽지 않다. 다행히 git 에서는 이를 위한 기능을 제공한다. 두 가지 방법이 있다. 하나는 --subject-prefix 를 이용하는 것이고, 다른 하나는 -v숫자 를 이용하는 것이다. --subject-prefix 일반적으로 format-patch 로 만들어진 패치 파일들의 제목은 [PATCH n/m] 형태이다. --subject-prefix 는 이 중에서 'PATCH' 를 지정된 문자열로 바꾼다. 예를 들어서 --subject-prefix "PATCH v2"  라고 하면 [PATCH n/m] 대신에 [PATCH v2 n/m] 형태가 된다. 하지만 패치 파일 이름의 형식은 달라지지 않는다. -v숫자 -v숫자 는 'PATCH' 문자열을 바꾸지 않고 대신에 'PATCH' 문자열 다음에 'v숫자' 를 추가한다. 예를 들어, -v3 라고 하면 [PATCH n/m] 대신에 [PATCH v3 n/m] 형태가 되며, --subject-prefix 와 달리 패치 파일 이름의 형식도 바꾼다. 파일 이름의 앞에 v숫자- 가 붙는다. 그리고 -v숫자 는 --subject-prefix 와 함께 쓰일 수 있다. 기본적으로 이 두 옵션은 format-patch 에서 쓰이지만, send-...

SubGit 은 git 를 이용해서 svn 저장소에 접근할 수 있는 기능을 제공하는 아주 강력한 도구이다. 하지만 가끔 svn 저장소에는 분명히 변경 사항이 있는데, git 에서는 보이지 않는 경우가 있다. 처음에는 svn 을 git 로 바꾸는 작업을 처음부터 다시 했었는데, svn 저장소가 매우 크다면 git 저장소로 바꾸는데 시간이 꽤 많이 걸린다. 그래서 좀 더 나은 방법이 없을까 생각해보다 찾아낸 것이 SubGit 의 install 명령을 다시 수행하는 것이다. 이미 있는 git 저장소에 subgit install 을 다시 수행하면 git 저장소에 아직 적용되지 않은 변경 사항만을 svn 저장소로부터 가져온다. 따라서 훨씬 시간이 줄어든다. 예를 들어, git 저장소가 ~/git/repo.git 이라면, subgit install ~/git/repo.git  을 하면, 다시 올바르게 작동한다. // ---- 2014/12/20 subgit 과 git 저장소를 원격 서버에 설치해서 쓰고 있는데, subgit 데몬이 시간이 좀 지나면 저절로 죽었다. 이게 꽤 빈번한터라, 매번 서버에 접속해서 subgit install 을 수행야 했는데, 정말 귀찮은 작업이었다. 그래서 더 좋은 방법이 있지 않을까해서 개발사에 물어보았다. 개발사의 설명은 이랬다. 일단 subgit 데몬이 죽는 이유는 로그 분석에 따르면 커널이 죽이는 것이라고 했다. 해결 방법으로는 메모리를 늘리거나 스왑을 설정하라라는 것이었는데, 관리자가 아닌 서버에 더부살이 하는 입장에서 그렇게 하기에는 힘들었다. 그리고 svn 저장소로부터 git 저장소로 변경사항들을 가져오려면 이를 위한 데몬이 실행되어야 하는데, 문제는 이 데몬이 자동으로 실행되지 않는다는 것이다. 데몬이 실행되는 경우는 두 경우라고 한다. 하나는 subgit install 이고, 다른 하나는 git push 이다. git pull 은 해당되지 않는다. 따라서 아무리 git pull 을 하더라도...

git is more and more used in open source projects. Fortuantely, git is available on OS/2, too. Here, I would introduce some useful settings on OS/2. core.autocrlf This sets how to process eol. If this is false, git does not convert eol at all. If it is true, eol is converted to LF on check-in, but converted to CR/LF on check-out. This is useful, but sometimes some shell scripts or unixy programs trigger errors due to eol problem. This is because shells and programs ported to OS/2, do not process eol with unified way. If it is input, eol is converted to LF on check-in, but git does not care eol of files in a working tree. I recommend this. but remember that REXX scripts should have CR/LF eol. For this, append [*.cmd eol=crlf] to .gitattributes file. In order to set, use this command, git config --global core.autocrlf input apply.whitespace EOL is always a problem. Some git commands refuse to process tasks due to whitespace, Primarily CR/LF. But, if you set this var...

svn 은 그 자체로 훌륭한 VCS 이지만, 로컬에서 패치를 관리해야 하는 순간, 지옥의 나락으로 떨어진다. 이를 해소하기 위한 방법에  git 가 있다. git 는 자체적으로 svn 저장소에 접근할 수 있는 기능이 있다. 바로 git-svn 이다. 이를 이용하면 svn 클라이언트가 없더라도 git 를 이용해서 svn 저장소를 관리할 수 있다. 그런데 불행히도 내가 주로 사용하는  OS/2 에서는 git-svn 이 제공되지 않고 있다. 이렇다 보니, git-svn 을 대신할 프로그램이 필요했는데, SubGit 이라는 프로그램이 있었다. 예전에는 SubGit 을 이용해서 svn 저장소를 git 저장소로 바꾸는데 이용했었는데, 이번에는 svn 저장소에 지속적으로 접근할 필요가 있었다. git-svn 처럼 SubGit 도 이런 기능을 제공하고 있었다. 그렇다면, git-svn 과 SubGit 중에 어느 것이 더 괜찮을까 ? 각각의 장단점을 간단하게나마 살펴보자. git-svn git-svn 은 git 가 대부분의 OS 에서 기본적으로 지원하고 있다. 따라서 별도의 프로그램이 필요없고 svn 저장소를 직접 접근하므로 별도의 저장소가 필요없다는 장점이 있다. 하지만 git-svn 은 기존의 git 명령 체계와는 다른 별도의 git-svn 명령 체계를 써야 한다는 점이 불편한다. 자칫 잘못해서 git-svn 대신 git 명령을 사용하면 로컬 저장소가 엉망이 될 수도 있다. SubGit SubGit 을 쓰기 위해서는 Java 1.6 이상이 필요하다. git-svn 과는 달리 별도의 프로그램이 필요하다는 것이 단점일 수 있겠지만, Java 는 이미 기본 프로그램으로 자리잡고 있으므로, 큰 문제는 아니라고 본다. 하지만 더 큰 문제는 git-svn 과는 다르게 SubGit 은 별도의 git 저장소를 만든다는 점이다. 따라서 SubGit 은 두 개의 저장소가 필요하다. 하나는 svn 저장소를 git 형태로 바꾼 git 서버 저장소. ...

git 를 사용하다보면 때때로 저장소 전체가 아니라 특정 브랜치 하나만 받고 싶을 때가 있다. svn 의 경우 디렉토리 단위로 받을 수가 있고, 브랜치도 하나의 디렉토리이기 때문에 별 어려움이 없었다. 하지만 git 에서는 이것을 어떻게 해야 할지 궁금했다. 구글링을 해 본 결과 clone 옵션 중에 -b(또는 --branch) 가 있었다. -b 옵션이 없으면 master 브랜치를 가져오고, -b 옵션이 있으면 해당 브랜치를 가져온다. git clone URL -b branch_name [dir] 그런데 사실 이것은, 저장소 전체를 가져와 HEAD 를 해당 브랜치로 바꾸는 것 뿐이다. 다시 말해서, HEAD 가 master 를 가리키는 것이 아니라 해당 브랜치를 가리키는 것이다. 결국 clone 하고나서 해당 브랜치를 checkout 한 것과 동등하다. git branch -r 을 해보면 전체 브랜치들이 모두 보인다. 그렇다면 실제로 해당 브랜치만 가져올 수는 없을까 ? 1.7.10(?) 부터 --single-branch 옵션이 추가되었다. 이 옵션을 사용하면 저장소 중에서 해당 브랜치만 clone 한다. git clone URL -b branch_name --single-branch [dir] 이것을 실행하고 나서 git branch -r 을 해보면 해당 브랜치만 나오는 것을 확인할 수 있다. 전체 저장소가 아니라 해당 브랜치에서만 작업하기를 원한다면 --single-branch 가 맞춤옵션이다. 게다가 전송 시간도 줄어들고 저장 장치에서 차지하는 용량도 줄어드니 더욱 좋다.

기존의 svn 저장소를 git 에서 이용하는 방법 중의 가장 대표적인 것은 git-svn 일 것이다. 그런데 사정상 git-svn 을 사용할 수 없어서, svn 저장소를 git 저장소로 바꾸는 방법을 찾아 보았다. 일단, 검색된 것은  svn2git 였다. 그런데 svn2git 는 ruby 가 있어야 했다. ruby 깔기도 귀찮고 해서 다른 방법을 찾아 보았는데,  SubGit 라는 것이 있었다. SubGit 은 Java 1.5 이상이 있어야 했지만, 다행히 Java7 이 깔려 있었다. 그래서 다운로드 페이지의 QuickStart 에 설명되어 있는 대로 바로 시도. 오~~~ 잘 된다. 이렇게 하면 자동으로 svn 저장소와 싱크가 된다고 한다. 하지만 나는 굳이 svn 저장소와 싱크를 원하지 않았다. 그래서 싱크하지 않는 방법은 없나 찾아보니, 역시나 있다. One-time import . 저장소를 바꾼 후에 git log 를 통해서 commit log 를 살펴봤더니, 작성자는 svn commiter 로 이메일은 commiter_id@local 로 바뀌었다. 이것을 바꾸는 기능은 없나 살펴봤더니, 역시나 있다. 필요로 하는 것은 다들 필요로 하는구나 싶은 순간. import 명령 도움말에 보면 --authors-file 옵션이 있다. 이를 이용하자. FILE 의 형식은 http://www.subgit.com/book-remote/index.html#authors-mapping 여기에서 확인. tag 도 깔끔하게 바뀌는 것을 확인했다. 다만 branch 가 없던 저장소라 branch 는 확인하지 못했지만, 잘 될 거라 믿어 의심치 않는다. 참, SubGit 은 평가용으로 원할 때까지 쓸 수 있지만 등록하라는 메세지가 나온다. 이게 싫다면 등록하면 된다. Free 용은 committer 10명까지, Open Source 용은 제한이 없는 것 같고, 상업용은 용도에 따라 가격이 달라진다. 내게는 어차피 한...

git 서버를 구축해봐야지 생각만 하다가 오늘 시도해 봤다. 의외로 간단했다. 하지만 관리자 권한이 없다보니 몇 가지 함정이 좀 있었다. 일단, apt-get 이나 yum 같은 설치 프로그램을 쓸 수 없었다. 그렇다면 귀찮지만 소스를 받아서 직접 빌드하는 수밖에... git 소스 타볼 을 받아서, 권한이 있는 디렉토리에 푼다.  예를 들면 디렉토리 관리를 위해 $HOME 에 work/git 를 만들어 그 곳에 푼다. 소스를 풀어 놓은 디렉토리에 가서 ./configure 를 실행시킨다. 이 때 꼭 권한이 있는 디렉토리를 --prefix 로 지정해 주자. --prefix 가 없으면 /usr/local 이 기본이 되는데, 관리자가 아닌 이상 그 곳에 권한이 없다. 역시 내 안방이 최고다. $HOME/usr 따위를 --prefix 로 지정해 주자. ./configure --prefix=$HOME/usr configure 가 끝나면 make 차례. make 도 끝나면 make install 을 날려준다. 이제 git 를 실행시킬 수 있다고 생각했지만, 정작 git 를 실행시키려고 하면 git 를 찾을 수 없다고 나온다. 이런... 이유는 PATH 때문이다. git 가 설치된 bin 디렉토리를 PATH 에 추가해 주자. export PATH=$PATH:$HOME/usr/bin 그럼 이제 되겠지 했는데, 웬걸 libiconv.so.2 가 없다며 난리다. 서버에 이미 설치가 되어 있다면 다행이지만, 이 서버에는 없나 보다. 또 설치해야지 뭐... ㅠㅠ libiconv 소스 를 받자. git 와 마찬가지로 빌드해서 설치하자. git 가 실행되겠지 하는 희망을 가지며, 실행해보지만, 여전히 같은 불평을 쏟아낸다. 하... 아까는 PATH 이번에는 LD_LIBRARY_PATH 가 문제다. libiconv 가 설치되어 있는 lib 디렉토리를 추가하자. lib64 도 있으면 같이 추가하자. export LD_LIBRARY_PATH=...