-1,49 +1 |
== # git-fancygraph == |
https://github.com/gypark/git-fancygraph |
장점: 음, 내가 만들었지만 예쁘다. :-) |
단점: 효율성이 꽝이다. git의 내부 동작 원리 이런 걸 잘 모른채로 프론트엔드 부분의 매뉴얼만 참고하면서 만든 거라... |
* <s>일단 <code>git log</code>를 두 번 실행해서 출력할 커밋 목록을 두 번 읽는다</s> |
** 한 번만 실행하도록 수정 |
* 읽은 후 다시 과거 커밋부터 거슬러서 읽으면서 각 브랜치들을 출력할 컬럼을 지정한다. 즉 전체 목록을 두 번 스캔함 |
* 커밋수가 몇만개씩 되는 (git소스같은) 곳에 쓰기에는 무리겠지. 하긴 누가 그런 곳에서 모든 브랜치의 그래프를 한꺼번에 보려 하겠냐만. |
* 특히나 <code>--split-merge</code> 옵션이 켜져 있으면 커밋 갯수가 많고 병합이 잦은 저장소에서는 무지무지하게 느려진다. <code>git merge-base</code>를 수도 없이 실행한다. |
== # 샘플 == |
다음 두 명령의 출력 비교 |
* <code>git log --oneline --decorate --color=always --source --graph 추가인자</code> |
* <code>git-fancygraph.pl 추가인자</code> |
* <code>추가인자2</code>는 출력할 브랜치 목록이나 파일명 등 |
'''샘플1''' |
Upload:sample1.png |
* <code>--all</code>로 모든 브랜치 출력 |
* 커밋 수는 28개밖에 안 되는데 그 와중에 브랜치가 6개나 되는 저장소. 테스트하기 적절한 환경 |
'''샘플2''' |
Upload:sample3.png |
* 추가인자를 <code>브랜치1 브랜치2 ^브랜치3 ^브랜치4</code> 이렇게 해서 브랜치1과 브랜치2에서 도달가능하지만 브랜치3과 브랜치4에서는 도달할 수 없는 커밋들만 출력시켜 보았음. 이렇게 커밋들의 부모자식 연결고리가 애매하게 깨질 때는 분기와 머지가 제대로 나오지는 않는다. |
'''샘플3''' |
Upload:sample2.png |
* [[UseModWiki소스수정]]의 2012년 2월 6일 현재 모습 |
* 이건 아주 맘에 든다. 지금처럼 브랜치 갯수는 많지 않으면서, 한쪽 브랜치에서 계속 커밋하고 다른 브랜치에서 머지하는 경우에 딱 좋아 보인다. |
<div class="comments"> |
<longcomments(100)> |
---- |
<trackbackreceived> |
</div> |
---- |
[[컴퓨터분류]] |
#REDIRECT GitFancygraph |