GitFancygraph

1. git-fancy

App::gitfancy

https://github.com/gypark/App-gitfancy

장점: 음, 내가 만들었지만 예쁘다. :-)

단점: 효율성이 꽝이다. git의 내부 동작 원리 이런 걸 잘 모른채로 프론트엔드 부분의 매뉴얼만 참고하면서 만든 거라...

• 일단 git log를 한 번 실행해서 출력할 커밋 목록을 두 번 읽는다
• 읽은 후 다시 과거 커밋부터 거슬러서 읽으면서 각 브랜치들을 출력할 컬럼을 지정한다. 즉 전체 목록을 두 번 스캔함
• 커밋수가 몇만개씩 되는 (git소스같은) 곳에 쓰기에는 무리겠지. 하긴 누가 그런 곳에서 모든 브랜치의 그래프를 한꺼번에 보려 하겠냐만.
• 특히나 --split-merge 옵션이 켜져 있으면 커밋 갯수가 많고 병합이 잦은 저장소에서는 무지무지하게 느려진다. git merge-base를 수도 없이 실행한다.
  • merge 커밋으로 합쳐지는 두 브랜치를 서로 구분할 ref가 없으면 하나로 나와버리기 때문에 그걸 일일이 뒤져서 분리해내주는 루틴인데... 원래의 git-log는 이걸 어떻게 처리하는 걸까나. 그걸 알면 좀 빠르게 할 수 있을지도.

2. 샘플

다음 두 명령의 출력 비교

• git log --oneline --decorate --color=always --source --graph 추가인자
• git-fancygraph.pl 추가인자
• 추가인자2는 출력할 브랜치 목록이나 파일명 등

샘플1

• --all로 모든 브랜치 출력
• 커밋 수는 28개밖에 안 되는데 그 와중에 브랜치가 6개나 되는 저장소. 테스트하기 적절한 환경

샘플2

• 추가인자를 브랜치1 브랜치2 ^브랜치3 ^브랜치4 이렇게 해서 브랜치1과 브랜치2에서 도달가능하지만 브랜치3과 브랜치4에서는 도달할 수 없는 커밋들만 출력시켜 보았음. 이렇게 커밋들의 부모자식 연결고리가 애매하게 깨질 때는 분기와 머지가 제대로 나오지는 않는다.

샘플3

• UseModWiki소스수정의 2012년 2월 6일 현재 모습
• 이건 아주 맘에 든다. 지금처럼 브랜치 갯수는 많지 않으면서, 한쪽 브랜치에서 계속 커밋하고 다른 브랜치에서 머지하는 경우에 딱 좋아 보인다.