merge 커밋은 ahead나 behind 갯수에서 제외하는 패치를 만들어보고 있는데요, 속도 문제가 있어서...

[gypark]

안녕하세요? 어제 git:todo plugin 포스트에 댓글 남겼던 Raymundo 입니다.

git todo를 써보면서 느낀 건데요.

--A1---A2---A3---A4---A5   branch A
   \     \    \         \
    B1----M1---M2--B2---M3  branch B

A1까지 진행한 상태에서 B라는 브랜치를 새로 만들고 위와 같이 진행되었을 때 A를 기준브랜치로 잡고 git todo 하면 B는 A보다 [+5] 진행한 걸로 나옵니다.

그러나 A를 B로 merge한 것은 A와 동일한 수정이니까 굳이 이걸 다 카운트할 필요가 없어보여서, B1과 B2만 ahead로 간주하도록 고쳐보았습니다. (실제로 제 저장소에서는 +22 중에 머지가 17개고 B만의 수정 커밋은 5개였거든요)

문제는, "A에 속한 커밋을 머지한 커밋"만을 찾아내야 하는데 그럴 효과적인 방법을 몰라서 branchB에 있는 모든 머지커밋들(M1,M2,M3)을 대상으로 각각

   git merge-base <커밋의 두번째 parent> <branchA>

하여 "merge-base값"이 <커밋의 두번째 parent>값과 동일한 것을 찾았거든요.

즉 git rev-list A..B --merges 해서 나오는 머지커밋의 수만큼 계속 git merge-base를 실행해야 해서... 수가 많으면 매우 느려집니다. 제 간단한 저장소에는 어차피 0.3~4초 정도 안에 출력이 나니까 상관이 없는데, progit 저장소에서 이걸 적용하면 적용하지 않았을때 1~2초 걸리던 게 15초 이상 걸리게 되는군요ㅎ

별 수 없이 이걸 옵션으로 결정할 수 있도록 바꾸긴 했는데,

혹시 이 상태에서 저렇게 제외할 머지 커밋의 갯수를 찾아낼 더 효과적인 방법이 있을런지, 고견을 듣고 싶어서 글 남깁니다. 제가 git 초보라서 ^^;

그럼 안녕히 계세요~

P.S. 혹시나 해서, 제가 수정한 부분은 다음 커밋입니다: https://github.com/gypark/git-tles/commit/e9f84f0e55960bf5576bc4f339deaa596abe2814

[pismute]

정확히 어떤 프로젝트에서 테스트해보신 건지. 말씀하신 시나리오를 구체적으로 알려주시면 고맙겠습니다. 이왕이면 제가 클론해서 테스트할 수 있는 프로젝트 였음 좋겠네요...

[gypark]

아니 뭐, 구체적이라고 해봐야 본문에 그린 상황 그대로라서 ^^, 제가 실제로 사용했던 저장소는 공개하기 곤란한 거라, 그냥 본문 그래프와 똑같은 상황의 저장소 하나를 만들어봤습니다.

https://github.com/gypark/todotest

(커밋 메시지까지 저 그래프와 딱 맞췄으면 좋았는데 그 생각을 못했군요)

master에서 계속 개발하는데, 이걸 실제 고객에게 전달할 때는 고객 맞춤 수정이 좀 필요해서, custom 브랜치에서 그런 수정을 하고, 이후 계속 master에서 개발하면 custom 브랜치에서 그걸 merge 하는 형태로 진행이 되는... 그런 상황을 가정한 거죠. (제 홈페이지에 쓰이는 위키소스를 이런 식으로 하고 있거든요. custom이 제 홈페이지 전용 브랜치인거죠)

어쨌거나 이 상황에서 git todo 를 하면 [+5] custom 이라고 나올텐데 (반대로 git todo custom 하면 [-5]master 일 테고) 따져보면 그 5개의 커밋 중에, custom 브랜치에서 실제로 커스텀 수정을 한 커밋은 두 개 뿐이고, 나머지 세 개는 단순히 master를 merge한 거니까, "master로부터 ahead"한 걸로 카운트하지 않아도 되지 않을까... 했던 겁니다.

(참고: https://github.com/gypark/todotest/compare/master...custom )

그래서 git todo (제가 패치한)에다 -m 옵션을 추가해서 git todo -m 하면 [+2]custom 으로 나오게 했지요.

여기서야 워낙 커밋 수가 적어서 속도 차이도 눈에 띄지 않습니다. 속도 차이를 제대로 체감하려면 progit 번역 작업 저장소에서 -a 옵션까지 주고 git todo -a -m ko 이렇게 하면 아주 그냥 ^^;;; 십수초씩 걸려버리네요.

[gypark]

아 그리고 오해하실까봐 첨언하면,

저는 pismite님이 만드시는 git todo의 동작이 이렇게 되어야 한다고 주장하려는 건 아니고요 :-) 그거야 만드시는 분 맘이니...

다만 제가 사용할 때는 그렇게 되었으면 싶어서 제가 혼자 쓸 패치를 그렇게 만들고 있는 건데 너무 비효율적으로 제외할 머지커밋을 찾고 있는 게 아닌가 해서, 혹시 이 상황에서 정확히 master->custom으로 머지된 커밋만 골라낼 방법이 있을까... 여쭤보려는 겁니다. ^^;

[pismute]

넵. 저는 그냥 --no-merges 옵션으로도 괜찮을 것 같아요.

정확한 요구사항은 말씀한 것과 다를 수 있어서... 이게 의도하신데로 인가요?

[gypark]

허억, 제가 바보였네요.

처음에 --no-merges 를 생각 안했던 게 아닌데,

--A1---A2---A3---A4---A5         master
   \     \    \         \
    B1----M1---M2--B2---M3---M4  custom
                             /
----------------------T1---T2    topic

위와 같은 경우가 있을 수 있으니까... 이 때 master를 기준으로 custom의 distance를 따지면, M1,M2,M3만 카운트하지 않고, M4는 카운트해야 하니까, --no-merges는 쓸 수 없겠다... 라고 생각했었던 거죠.

그런데 지금 다시 생각하니까 M1,M2,M3를 제외하는 이유가 그대로 M4에도 적용되는군요. 실질적인 수정이 일어난 커밋만 카운트하자는 게 취지였으니,, B1,B2,T1,T2 이렇게 4개 토픽에서만 수정이 이뤄진 거니까 [+4]custom 으로 표시하는 게 틀린 게 아니었네요. OTL

괜히 복잡하게 생각해서 일을 어렵게 만들었군요. 감사합니다 ^_^

[pismute]

커밋 메시지에 #3처럼 이슈 번호를 넣으면 됩니다. 그리고 push하면 해당 issue에 연결됩니다.

옵션을 git config todo.merge no처럼 설정할 수도 있게 만들면 더 좋을 것 같아요...

[gypark]

감사합니다 ^_^