[첫화면으로]Git

마지막으로 [b]
1. 좌충우돌하며 시작
1.1. 검색하며 눈에 띈 문서들
1.2. cmd 대신 ckw 쓰기
1.3. 벨소리 없애기
1.4. 한글 출력
1.5. 에디터 바꾸기
1.6. 그 외
2. 커밋 메시지의 인코딩
3. Merge와 Diff를 외부 프로그램 쓰기
3.1. vimdiff로 Merge
3.2. p4merge로 Merge
3.2.1. 시스템 디폴트 인코딩(cp949)를 쓸 경우
3.2.2. UTF-8로 인코딩을 쓰는 경우
3.3. vimdiff로 diff
3.4. p4merge로 diff
3.5. DiffMerge로 merge, diff 하기
4. 두 저장소를 잇기
5. SSH로 서버에서 받아올 때 PATH 문제
6. CVS에서 Git로 이전하기
7. 한글 파일,폴더명 표기 문제
8. 출력을 무조건 cp949 로 변환
9. 복잡해져서 별도 페이지로 분리한 내용들
9.1. 브랜치
9.2. git rebase
9.3. git reset
9.4. 복구
9.5. 서브프로젝트
9.6. 그 외, 이럴 땐 이렇게
10. 기타
11. git version 2.6.2 에서의 한글 사용
11.1. 설치
11.2. 터미널에서 한글 처리
11.3. git에서의 한글 처리
11.4. 기존 저장소 이전
11.5. 시작 디렉토리
11.6. 그 외
12. Comments

한글과 관련된 문제에 대해서는 아래의 버전 2.6.2 절을 우선 볼 것

1. 좌충우돌하며 시작

리눅스에서는 설치하고 바로 사용하는데 큰 문제가 없는데, 윈도에서 msysgit 을 쓰자니 특히나 한글 처리 등 이런저런 문제들이 있었음.

1.1. 검색하며 눈에 띈 문서들

1.2. cmd 대신 ckw 쓰기

(최신 버전에서는 굳이 다른 대체품을 찾을 필요가 없다. 버전 2.6.2 절 참고.)

1.3. 벨소리 없애기

(버전 2.6.2 절 참고.)

1.4. 한글 출력

(버전 2.6.2 절 참고.)

1.5. 에디터 바꾸기

commit할 때 사용하는 에디터를 gvim으로 바꾸고 싶으면 GIT_EDITOR 환경 변수를 정해주면 됨. 다만 bash를 거치기 때문에 경로를 다음과 같이. 
export GIT_EDITOR=/d/Local/Vim/vim72/gvim.exe

VimEditor 7.2부터는 git 설정파일 등의 신택스 하일라이팅이 지원되는데, 그 이전 버전은 다음과 같이 하면 된다8

1.6. 그 외

(버전 2.6.2 절 참고.)

2. 커밋 메시지의 인코딩

(버전 2.6.2 절 참고.)

3. Merge와 Diff를 외부 프로그램 쓰기

위에 있는 "Pro git" 번역판 7장에 "다른 Merge, Diff 도구 사용하기" 섹션이 있는데, 윈도우에서 하려니 잘 안 되는 부분이 있어서, 이래저래 구글링도 하고 직접 테스트 하면서 알아낸 것 정리.

일단 책에 소개된 P4Merge[9]와, VimEditor를 쓰는 걸 생각해 보자.

3.1. vimdiff로 Merge

git merge를 했을 때 충돌이 나서 자동으로 merge할 수 없다고 나오면, get mergetool 명령을 써서 병합 도구를 띄울 수 있는데, 이 때 vim을 띄우는 세팅: 

[merge]
        tool = vimdiff
[mergetool "vimdiff"]
        path = d:/Local/Vim/vim72/gvim.exe

3.2. p4merge로 Merge

p4merge는, 소스 파일들이 주로 어떤 인코딩으로 저장되어 있냐에 따라 좀 다르다.

3.2.1. 시스템 디폴트 인코딩(cp949)를 쓸 경우

병합할 대상 파일들이 주로 cp949로 인코딩되어 있다면, 비교적 간단(?)하게 가능하다: 
[merge]
        tool = p4merge
[mergetool "p4merge"]
        path = c:/Program Files/Perforce/p4merge.exe

$ git config mergetool.p4merge.path /c/Program\ Files/Perforce/p4merge.exe

3.2.2. UTF-8로 인코딩을 쓰는 경우

소스 코드 파일들이 UTF-8로 인코딩되어 있다면... 이러면 좀 더 복잡해진다. p4merge는 실행 후 메뉴에서 인코딩을 바꿀 수 있다. 따라서 위처럼 설정하고 p4merge를 실행할 때마다 직접 바꿔줘도 되겠지만 귀찮다.

또 p4merge는 명령행 옵션을 써서 인코딩을 옵션으로 줄 수도 있다! 그런데, 문제는 Git가 p4merge를 불러오는 과정에서 그 옵션을 삽입하게 할 방법이 없다10

별 수 없이, wrapper 스크립트를 만든다. 
#!/bin/sh
/c/Program\ Files/Perforce/p4merge.exe -C utf8 "$1" "$2" "$3" "$4"

그리고 .git 옵션에서는 p4merge의 path를 저 스크립트로 바꿔치기 한다. 
[merge]
        tool = p4merge
[mergetool "p4merge"]
        path = c:/Program Files/Git/bin/extMerge

(사실 내가 merge를 직접 해야 할 일이 얼마나 있을까 생각해보면... 그냥 처음처럼 두어도 되었을 걸 -_-)

3.3. vimdiff로 diff

diff는 merge하고 상황이 다른데, merge야 충돌 나면 그때가서 충돌난 파일을 에디터로 열어서 손으로 찾아가며 해도 되지만, diff는 git diff를 할 때마다 터미널 창에 뜨는데 UTF-8은 다 깨져나와서, 별 수 없이 리다이렉션으로 일단 저장하고 열어보는 수고를 해야 한다. 아니면 파이프로 iconv에게 넘겨줘도 되는데 이러면 색상 구분이 다 없어져 버린다.

일단 vimdiff로 diff를 보는 것부터 얘기하자.

diff도 두가지가 있다.

git difftool에서만 vim을 쓰고 싶다면 툴만 지정해주면 된다. gvim을 원한다면 merge할 때와 같이 path도 지정. 
[diff]
       tool = vimdiff

git diff에서도 vim을 쓰고 싶다면 좀 복잡하다. 여기에는 vimdiff 프리셋 같은 게 없어서 일일이 명령어와 인자를 명시해줘야 한다.

여기서도 wrapper 스크립트를 만들어주자. Git bash 상에서 /bin/extDiff 스크립트를 만든 후, 다음과 같이 적는다: 
#!/bin/sh
/d/Local/Vim/vim72/gvim.exe -d "$2" "$5"

그 다음 gitconfig 에서는 diff.external 값을 설정한다: 
[diff]
        external = extDiff

3.4. p4merge로 diff

이게 아주 해괴망칙한 부분인데...

두 커밋 또는 커밋과 작업 디렉토리 등을 비교할 때, 파일이 양쪽에 다 존재하면 괜찮은데, 중간에 파일을 새로 생성했다거나 삭제를 했다면 어느 한쪽에는 파일이 없다. 문제는 그 없는 파일이 diff를 할 때 /dev/null이라는 경로명으로 diff 프로그램에 넘어간다는 거다. Git의 기본 diff는 이걸 잘 처리해주고 (빈 파일처럼 다루어 비교함), vimdiff도 마찬가지인데, p4merge 는 인자로 이 이름을 받으면 잘못된 파일이라고 에러를 낸다.

(이 문제에 대해서는 stackoverflow를 비롯해서 구글링을 여러 차례 해도 나오는 게 없더라. 윈도 msysgit에서 p4merge를 사용하는 법을 묻는 질문은 종종 있던데, 다들 이 문제는 포기하고 살았던 걸까, 아니면 나만 겪고 있나?)

어차피 인코딩 옵션 때문에 wrapper 스크립트를 쓰긴 해야 하는데, 이 문제 때문에 인자를 미리 검사해서 p4merge를 속이는 일도 해줘야 한다. diff와 difftool 양쪽에서 다 p4merge를 쓰는 경우를 가정하자.

wrapper 스크립트는 다음과 같이 작성한다. 
#!/bin/sh

# %TEMP% 디렉토리에 저장될 임시파일명. PC내에서 절대 겹치지 않을 것 같은 이름을 지어준다
BLANKFILE="${TEMP}/_blank_"

if [ $# -eq 7 ]
then
        # 'git diff'
        LOCAL=$2
        REMOTE=$5
else
        echo "I got $# arguments. ERROR!"
        exit 1
fi

if [ "$LOCAL" == '/dev/null' ]
then
        touch $BLANKFILE
        LOCAL=$BLANKFILE
fi
if [ "$REMOTE" == '/dev/null' ]
then
        touch $BLANKFILE
        REMOTE=$BLANKFILE
fi
/c/Program\ Files/Perforce/p4merge.exe -C utf8 "$LOCAL" "$REMOTE"
rm -f $BLANKFILE

그리고 git에서는 다음과 같이 설정 
[diff]
        external = extDiff
        tool = extDiff
[difftool "extDiff"]
        cmd = extDiff \"\" \"$LOCAL\" \"\" \"\" \"$REMOTE\" \"\" \"\"

[P4Merge를 사용한 diff 스크린샷] - 왼쪽 창은 비교 대상 중 한쪽에 파일이 없는 경우. 실제로는 저렇게 창들이 한꺼번에 뜨지 않고, 파일 하나마다 뜨고 닫으면 다음 창이 뜬다.

3.5. DiffMerge로 merge, diff 하기

아래는 DiffMerge를 언급하는 글들

글을 보고 호기심이 나서 설치해 봄.

git mergetool할 때 사용하기 위한 설정은 쉽다. 위에 링크된 글들을 참고하고, 나는 다음과 같이 .gitconfig파일에 적었다. 
[merge]
        tool = diffmerge
[mergetool "diffmerge"]
        cmd = \"c:/Program Files/SourceGear/Common/DiffMerge/sgdm.exe\" --merge --result=\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"
        trueExitCode = true

뒤에 인자를 적는 부분에 꼬박꼬박 따옴표를 해 준 이유는, 역시 파일명에 공백이 있을 경우를 대비해서.

diff는, p4merge와 같은 이유로 귀찮다.

일단 git difftool을 위한 간단한 설정은: 
[diff]
        tool = diffmerge
[difftool "diffmerge"]
        cmd = \"c:/Program Files/SourceGear/Common/DiffMerge/sgdm.exe\" \"$LOCAL\" \"$REMOTE\"

그러나 p4merge에서처럼, 만일 두 스냅샷을 비교하는데 파일이 어느 한쪽에서만 존재하면, 존재하지 않는 쪽이 "nul"이라는 파일명으로 넘어가는 바람에 에러창이 뜨고, 에러창을 닫으면 또 DiffMerge창도 무의미하게 한 번 더 닫아줘야 한다.

그래서 할 수 없이 wrapper를 만든다. 내 경우는 다른 건 다 p4merge에서와 똑같이 하고, extDiff 스크립트 내에서 프로그램 호출하는 부분만 바꿔 적었다. 
# 이건 그대로
[diff]
        tool = extDiff
[difftool "extDiff"]
        cmd = extDiff \"\" \"$LOCAL\" \"\" \"\" \"$REMOTE\" \"\" \"\"


# /c/Program\ Files/Perforce/p4merge.exe -C utf8 "$LOCAL" "$REMOTE" 이거 대신
/c/Program\ Files/SourceGear/Common/DiffMerge/sgdm.exe "$LOCAL" "$REMOTE"

git diff의 경우는 diff.external 옵션값을 extDiff로 바꿔주면 되겠으나, 그동안 좀 더 사용하다보니까 git diff는 터미널에서 그냥 하는 게 나을 때도 많고 해서 이건 건드리지 않았다. (위에 dogfeet님 블로그 글과 같은 이유)

끝으로, DiffMerge는 기본 텍스트 인코딩을 ISO-8859인가로 잡아놨기 때문에 한글이 포함된 문서를 볼 때 제대로 안 보인다.

4. 두 저장소를 잇기

5. SSH로 서버에서 받아올 때 PATH 문제

리눅스 서버에 git 저장소를 하나 만들고, 그걸 윈도우 머신에서 복사하려고 (github를 거치지 않고) 시도했는데 아래와 같이 에러가 났다. 
$ git clone gypark@gypark.pe.kr:/home/gypark/temp/cvstest/testwiki.git
Cloning into 'testwiki'...
gypark@gypark.pe.kr's password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

서버의 내 아이디 gypark에서 git-upload-pack을 실행시킬 수 없었던 건데, 이 시점에서는 .bashrc만 적용되고 .bash_profile에 있는 $PATH 설정은 적용이 안 되더라. .bashrc쪽에서 PATH를 지정해주어 해결

6. CVS에서 Git로 이전하기

CVS로 관리하던 UseModWiki소스수정을 github로 옮겼는데, 그간 중앙 집중형 버전관리시스템의 대세가 확실히 Subversion으로 넘어갔던 건지, svn에서 이전하는 건 Git 자체에서도 지원하는 듯 한데, CVS에서 옮기는 얘기는 은근히 잘 찾을 수가 없더라. cvs-svn-git로 두 번 넘어가야 하나, 그간 수백번의 리비전이 있었는데 제대로 옮겨지려나 걱정을 많이 했다. 그런데 막상 해보니, Git를 만져본 후 이게 가장 쉬웠다고 할 정도로 무난히 성공했음.

필요한 것:

절차: 
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
    ...
    # GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'),
    GitRevisionRecorder('/home/gypark/temp/cvstest/testwiki-blob.dat'),
    )

# ctx.trunk_only = False
ctx.trunk_only = True

ctx.cvs_author_decoder = CVSTextDecoder(
    [
        #'latin1',
        #'utf8',
# gypark
        'utf8',
        'cp949',
        'ascii',
        ],
    #fallback_encoding='ascii'
    )
ctx.cvs_log_decoder = CVSTextDecoder(
    [
        #'latin1',
        #'utf8',
# gypark
        'utf8',
        'cp949',
        'ascii',
        ],
    #fallback_encoding='ascii'
    )
# You might want to be especially strict when converting filenames to
# Unicode (e.g., maybe not specify a fallback_encoding).
ctx.cvs_filename_decoder = CVSTextDecoder(
    [
        #'latin1',
        #'utf8',
# gypark
        'utf8',
        'cp949',
        'ascii',
        ],
    #fallback_encoding='ascii'
    )

# ctx.username = 'cvs2svn'
ctx.username = 'gypark'

author_transforms={
    ...
# gypark
    'gypark'  : ('내 이름', '내메일주소'),
    }

ctx.output_option = GitOutputOption(
    # The file in which to write the git-fast-import stream that
    # contains the changesets and branch/tag information:
    # 'cvs2svn-tmp/git-dump.dat',
    '/home/gypark/temp/cvstest/testwiki-dump.dat',
    ...
    )

run_options.set_project(
    # The filesystem path to the part of the CVS repository (*not* a
    # CVS working copy) that should be converted.  This may be a
    # subdirectory (i.e., a module) within a larger CVS repository.
    # r'test-data/main-cvsrepos',
    r'/home/gypark/CVS/testwiki',
    ...
    )

$ cvs2git --options=옵션파일이름

$ mkdir testwiki.git
$ cd testwiki.git
$ git init

$ cat ../testwiki-blob.dat ../testwiki-dump.dat | git fast-import

여기까지가 정말 일사천리로 끝났다. 위에서 변환한 건 euc-kr을 사용하던 ext1.* 버전의 저장소인데, 총 커밋 횟수가 480회 정도 되고, 중간에 커밋 메시지가 에디터 설정 실수로 UTF-8로 끼어든 것들도 여럿 있고 그랬다. 그런데 전혀 에러나 오류 없이 깔끔히 변환되었다. 도저히 한번에 성공할 거라 생각하지 못해서, 일단 연습용 CVS저장소를 새로 만들고 커밋을 몇 번 한 후 변환을 시도하며 연습했었는데, 연습할 필요조차 없었지 싶다. 감탄했음.

그 다음은 UTF-8 기반으로 시작한 ext2.* 버전 저장소를 변환했다. 설정 파일에서 저장소 위치와 덤프 파일 이름만 바꿔주고는 한번에 성공.

이러고 나니까, 이왕 옮긴 김에, 두 Git 저장소를 하나로 통합하고 싶어졌다. ext1.* 버전에서 ext2.* 버전으로 죽 변경내역이 이어지도록 이어 붙이고 싶어진 것이다.

이건 어렵지 않게 구글링으로 성공했다. 위에 두 저장소를 잇기절에 있는 내용을 참고. 
[gypark@www UseModKr]$ git rev-list --reverse master | head -1
92de4e3fdcd017fa0692069d3dcb57e93ab5bcec

[gypark@www UseModKr]$ cat ../testwiki-blob.dat ../testwiki-dump.dat | git fast-import
warning: Not updating refs/heads/master (new tip 65919c894b1e19183c380d27093b5a08089186c1
does not contain 1fe3f81b4760efa38911f49905b0241eaaea3848)

[gypark@www UseModKr]$ echo 92de4e3fdcd017fa0692069d3dcb57e93ab5bcec \
65919c894b1e19183c380d27093b5a08089186c1 >> .git/info/grafts

[gypark@www UseModKr]$ git log --pretty=oneline
...
0be974ced4a7ab8212142666c321cbd66b170584 SlashLinks 옵션을 1로 켜고 관련 변수들을 절대 경로
92de4e3fdcd017fa0692069d3dcb57e93ab5bcec utf-8로 저장                          <-- ext2.* 버전의 첫 커밋
65919c894b1e19183c380d27093b5a08089186c1 *** empty log message ***             <-- ext1.* 버전의 마지막 커밋
8a90c0f4c323d44481184d97e42b3de5422ac4ed index 매크로 수정 - 인쇄할 때 인덱스 넘버를 출력하
...

$ git filter-branch --tag-name-filter cat -- --all
$ rm .git/info/grafts

위 과정 중에서, 이전 저장소를 가져오는 부분의 더 깔끔한 방법: 
[gypark@www UseModKr]$ git fetch ../testwiki.git master:old-history

$ git rev-parse old-history
65919c894b1e19183c380d27093b5a08089186c1

최종 결과물:

7. 한글 파일,폴더명 표기 문제

[msysgit 으로 윈도우에서 git을 쓸 때 한글로 된 파일,폴더명이 깨져서 나오는 문제 | KLDP] - 이게 꽤나 불편함

Upload:git_korean.png

KLDP의 답글을 보고 1.7.10을 설치했는데, 이 문제는 해결되지 않고 오히려 bash 창에서 한글 입력이 안 되고 기존 한글 폴더명들이 죄다 git status에서 삭제된 걸로 나오는 등 상황이 악화되었다. 1.7.8로 부랴부랴 다운그레이드. 현재 해결책 모름.

중간 정리: http://kldp.org/node/132431#comment-584574

으윽, 나중에 발견했는데 이건 리눅스에서도 마찬가지였으며, core.quotepath 옵션이 있어서 이걸 false로 해주면 안 깨지는 거였다. (윈도우에서는 여전히 문제가 좀 있지만)

8. 출력을 무조건 cp949 로 변환

앞 섹션의 파일명 문제도 그렇고, UTF-8로 인코딩된 문서를 윈도우 명령 프롬프트 창에서 diff 를 보거나 (또는 반대로 euc-kr 문서를 리눅스에서 보거나) 등등 할 때마다 글자가 깨지니까, 그냥 필터를 하나 만들어서 보기로 함(이 코드 자체는 뭐 git에서만 쓰는 게 아니라 범용이지만) 

#!/usr/bin/env perl
# git diff 의 출력을 받아서 인코딩을 변환하여 출력
# 예: git diff --color | cat_encode.pl
use strict;
use warnings;

use Encode;
use Encode::Guess;

my $pat_color = qr/(?:\e\[[;\d]*?m)/;
my @ansi = ();
my $output_encoding = 'cp949';

while ( my $line = <> ) {
    chomp $line;

    # ANSI 색상지정 코드를 일단 제거
    $line =~ s/($pat_color)/save_ansi($1)/eg;

    my $enc = guess_encoding( $line, qw/cp949/ );
    if ( not ref($enc) ) {
        print "!!! ", $line, "\n";
        next;
    }
    my $str = encode($output_encoding, $enc->decode($line));

    # ANSI 코드 복원
    $str =~ s/___ansicode\((\d+)\)___/$ansi[$1]/eg;
    print $str, "\n";
}

sub save_ansi {
    return '' unless ( -t STDOUT);

    my $ansi = shift;
    push @ansi, $ansi;
    return "___ansicode($#ansi)___";
}

그러면 git status | cat_encode.pl 등과 같이 쓸 수 있는데, 이번엔 뭐가 문제냐 하면 git 에서 출력을 할 때, 터미널로 출력을 안 하는 경우는 ANSI 컬러 코드를 출력하지 않아서 출력이 한 가지 색상으로만 나온다는 점이다(컬러 설정 값이 auto일 때). 이걸 또 손봐야 한다.

그리고 매번 파이프를 쓰기 귀찮으니 alias 설정을 할 수도 있겠다.

9. 복잡해져서 별도 페이지로 분리한 내용들

9.1. 브랜치

/Branch

9.2. git rebase

/Rebase

9.3. git reset

/Reset

/ResetDemystified번역

9.4. 복구

/복구

9.5. 서브프로젝트

/서브프로젝트

9.6. 그 외, 이럴 땐 이렇게

/이럴땐이렇게

/저장소병합

10. 기타

/작업흐름 - UseModWiki소스수정에 git을 쓰는 예

[An asymmetry between git pull and push « Mark’s Blog]

[여름으로 가는 문 - 번역: 서브버전 사용자를 위한 머큐리얼(mercurial)이전 가이드]

[A Visual Git Reference]

[version control - git workflow and rebase vs merge questions - Stack Overflow]

[Git for Computer Scientists]

[dogfeet - Git:번역 Workflow]

[완전 초보를 위한 깃허브]

[It happened: Git 2.0 is here and it's full of goodies - Atlassian Blogs]

[Git for Windows Unicode Support · msysgit/msysgit Wiki · GitHub] - 새 PC에서 지금 파일명 때문에 난리가 났음.

[A Visual Git Reference]

[Git과 Subversion] Git에서 subversion 저장소를 사용하여 pull, push하기

[git diff와 git log에서 ..와 ...]

11. git version 2.6.2 에서의 한글 사용

2015년 10월. 집에서 쓰는 데스크탑을 새로 구입하고 윈도우10을 설치하면서 git도 새로 설치하는데, 버전이 바뀌면서 한글 관련해서 여러가지가 바뀌었다.

전체적으로, 기존의 각종 번잡한 설정을 추가하지 않고서도 훨씬 편하게 한글을 사용할 수 있다.

11.1. 설치

설치할 때 특별히 기본값 대신 설정해준 것들:

11.2. 터미널에서 한글 처리

git bash 를 띄워보면... 한글이 그냥 잘 되는 것 같다 (아직 많이 써 본 게 아니라서 확신은 못하지만)

11.3. git에서의 한글 처리

일단 파일명의 non-ASCII 캐릭터들을 \숫자 형태로 변환하지 않도록 옵션을 주자. 

git config --global core.quotepath off

이제 기존 저장소에 가서 git status를 했더니... 

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    %$@%$@%@.txt    <-- 깨진 글자

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        한글이름.txt

no changes added to commit (use "git add" and/or "git commit -a")

이렇게 한글이름 파일들은 전부 stage와 untracked에 동시에 나온다. stage에서는 글자가 와장창 깨진 이름으로 나오면서 지워진 걸로 나온다. git이 기존에 저장한 파일명과 현재 파일명을 서로 다른 이름으로 해석하고 있는 눈치이다.

이 깨진 파일명을 어떻게 수작업으로 하려고 해도, 그 이름의 파일을 찾지 못하여서 not match 어쩌고 하면서 아무것도 안 된다. 그래서 그냥 지금까지의 이력을 날려버리고 저장소를 새로 시작해야 하는가 했는데, 찾아보니 이와 관련한 문서가 있음

11.4. 기존 저장소 이전

[Git for Windows Unicode Support · msysgit/msysgit Wiki · GitHub]

이 글에 "Migrating old Git for Windows repositories" 절을 참고한다.

1. 일단 저장소를 untracked 파일이 없는 깨끗한 상태로 만든다. 

/c/git1.7.9/bin/git clean -f && /c/git1.7.9/bin/git reset --hard


git clean -f && git reset --hard

2. 기존에 저장된 인덱스를 삭제하고, 파일들을 전부 새로 추가한다. 

git rm -rf --cached \* && git add --all

3. git status를 해 보면 "깨진파일명 => 한글파일명" 상태로 이름이 바뀌어서 커밋 대기중인 상태로 나오는 거 확인한 후 커밋. 
git commit -m "UTF-8 conversion"

11.5. 시작 디렉토리

터미널로 ckw.exe 를 쓸 때는 시작 디렉토리를 지정할 수 있었는데 mintty에서 git-bash.exe 를 띄우는 현재 상황에서는 모르겠다.

~/.bashrc 파일에다가 cd /d/git 같은 식으로 적어주어 해결 -_-

11.6. 그 외

위 과정까지 거치고 나면, 그 다음은 중간중간에 다시 한글이 깨져서 어라 싶었던 경우가 있는데, git을 새로 설치하고 기존에 했던 각종 한글관련 설정을 하지 않은 상태에서 다시 재현하려고 하니 잘 되지 않는다. 아마 뭔가 기존 설정값이 문제였던 듯.

어쨌거나 1.7.9나 그 이전 버전을 쓸 때에 비하면 훨씬 터미널 환경에서 쓰기 편해진 느낌이다. 그런데 웬만하면 source tree 같은 걸 쓰는 게 나아보이기도. 나는 계속 리눅스나 맥의 커맨드 라인에서 쓰다보니 GUI가 낯설어서 그렇지만...

12. Comments

아 너무 좋은 글입니다.
msysgit 에잇하고 포기하고 있었는데 다시 도전해봐야 겠네요.
잘보겠습니다. 감사합니다.
-- 박창우 2012-4-12 10:26 pm

사실 지금도 diff 등을 볼때 UTF-8 인코딩된 소스코드들의 한글이 와자작 깨져서 콘솔 창에서 못 보고 일일이 GUI툴을 띄우거나... 그래서 "에잇" 소리는 자주 나옵니다 ^^;
-- Raymundo 2012-4-12 10:42 pm

win7 64 home premium eng 버전을 사용하고 있는데,
이유는 모르겠지만 위에 설명하신대로는 실행이 안됩니다.
다음 처럼 실행하니 되는 군요.

"D:\local\ckw.exe" -e "C:\Program Files (x86)\Git\bin\sh.exe" -login -i
-- 박창우 2012-5-2 9:25 am

오홍, 저는 지금 윈XP 사용 중이라... 위에도 적어두겠습니다 감사합니다.
-- Raymundo 2012-5-2 2:16 pm

윈도에 git 설치하던 초반에 한글 관련해서 가장 도움이 되었던 내용입니다.
종종 참조하곤 합니다. 감사합니다^^
-- 아폴로 2013-7-31 5:49 pm

도움이 되었다니 저도 기분 좋네요. 근데 솔직히 윈도우에서 쓰려면 일단 한글 인코딩부터 시작해서 형편없는 명령프롬프트 창에... 그냥 gitk 같은 걸 쓰는 게 나을지도 모르겠어요 ^^;
-- Raymundo 2013-7-31 6:13 pm

유난히 이 페이지에 스팸이 많이 들어와서, 코멘트 입력창은 지움.
-- Raymundo 2015-10-2 3:26 pm

컴퓨터분류

각주:
1. 매뉴얼[1] 참고
2. [2]
3. [3]
4. [4]
5. 6. [5]
7. [6]
8. git소스 디렉토리의 contrib/vim/README
9. [7]
10. C:\Program Files\Git\libexec\git-core\mergetools\p4merge 스크립트 참조 [github에서 보기]. path값에 옵션을 추가하더라도, 저 스크립트에서 따옴표로 둘러싸여 있으므로 통채로 실행하려고 해서 에러가 난다.
11. "Pro Git"을 읽어봐도 그렇고 github 등을 읽어봐도 그렇고, 일단 외부에 push해서 남이 가져간 커밋을 나중에 고치는 건 절대로 피해야 할 일이라고 하니 주의

마지막 편집일: 2020-5-8 11:28 am (변경사항 [d])
17266 hits | Permalink | 변경내역 보기 [h] | 페이지 소스 보기
0.337 sec 처음으로 [t]