Coder Social home page Coder Social logo

githru-vscode-ext's Introduction

Githru

Visual Analytics for Understanding Software Development History Through Git Metadata Analysis

Githru is an interactive visual analytics system that enables developers to effectively understand the context of development history through the interactive exploration of Git metadata. We design an interactive visual encoding idiom to represent a large Git graph in a scalable manner while preserving the topological structures in the Git graph.

To enable scalable exploration of a large Git commit graph, we propose novel techniques (graph reconstruction, clustering, and Context-Preserving Squash Merge (CSM) methods) to abstract a large-scale Git commit graph. Based on these Git commit graph abstraction techniques, Githru provides an interactive summary view to help users gain an overview of the development history and a comparison view in which users can compare different clusters of commits.

Demo

Visit our Demo page!!

References

Youngtaek Kim, Jaeyoung Kim, Hyeon Jeon, Young-Ho Kim, Hyunjoo Song, Bohyoung Kim, and Jinwook Seo, "Githru: Visual Analytics for Understanding Software Development History Through Git Metadata Analysis", IEEE VIS 2020 (VAST)

Apply to your repo!!

TBD

Video Preview

TBD

Citation

bibtex

@ARTICLE{kim2021tvcg,
  author={Kim, Youngtaek and Kim, Jaeyoung and Jeon, Hyeon and Kim, Young-Ho and Song, Hyunjoo and Kim, Bohyoung and Seo, Jinwook},
  journal={IEEE Transactions on Visualization and Computer Graphics}, 
  title={Githru: Visual Analytics for Understanding Software Development History Through Git Metadata Analysis}, 
  year={2021},
  volume={27},
  number={2},
  pages={656-666},
  doi={10.1109/TVCG.2020.3030414}}

Install and Run

git clone https://github.com/githru/githru.git
cd frontend
npm i
npm start

visit

githru-vscode-ext's People

Contributors

2taesung avatar allcontributors[bot] avatar anpaul0615 avatar ansrlm avatar blcklamb avatar hanseul-lee avatar hiitmemario avatar hy57in avatar inthejim avatar jejecrunch avatar jeonghye-choi avatar jin-pro avatar jinho1011 avatar keepgo-studio avatar kkanghh avatar kyutae98 avatar newgardener avatar ooooorobo avatar pcwadarong avatar pshdev1030 avatar rbgksqkr avatar rlaqltmxm avatar seoes avatar seungineer avatar taejs avatar vgihan avatar wherehows avatar xxxjinn avatar ytaek avatar yuiseo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

githru-vscode-ext's Issues

[bug][engine] CSM squash 대상 중에서 머지커밋을 식별하는 로직 오류

문제 개요

  • 현재 CSM 처리과정 내 squash 대상 선정을 위한 머지커밋 식별 로직 오류가 있습니다.

    • 머지커밋 식별 로직에서 특정 커밋히스토리를 제대로 해석하지 못하는 현상이 발생합니다.
  • 사례
    image

    => git log 히스토리 상으로는 fd46b 는 CSM-base 이고, 3af7b 를 CSM-source 로 가지는 CSMNode 입니다.
    => 하지만 buildCSMDict 결과(아래 스니핏)상에서는 전혀 엉뚱한 CSM-base(00ff22) 하위 source 로 들어가고 있습니다.

          {
            base: {
              commit: {
                sequence: 176,
                id: '00ff228a790fb60f61d076a3d2a9e10b96444e65',
                parents: [
                  'aa4b04d2fac243441a8549a7cddc51951628210e',
                  '5781ae0bc1aa8f6a542e91ce642328fb9fc19fc0'
                ],
                branches: [],
                tags: [],
                author: { name: 'ytaek', email: '[email protected]' },
                authorDate: 'Wed Aug 17 17:07:32 2022 +0900',
              },
              stemId: 'main'
            },
            source: [
              {
                commit: {
                  sequence: 21,
                  id: 'e2153053a6cc4ae749b28d5586868334c2fa1829',
                  parents: [ '3240fdea033437bbfb7374853abc856be89c2968' ],
                  branches: [ 'main' ],
                  tags: [],
                  author: { name: '조예진', email: '[email protected]' },
                  authorDate: 'Thu Sep 8 19:50:25 2022 +0900',
                  committer: { name: 'GitHub', email: '[email protected]' },
                  committerDate: 'Thu Sep 8 19:50:25 2022 +0900',
                  message: 'feat(engine): Implement STEM ... ',
                },
                stemId: 'main'
              },
              // ...
              {
                commit: {
                  sequence: 70,
                  id: '6068366d332e15aa5d474d9f918d32aea25bc002',
                  parents: [
                    'fd46b07926bce8745ebe83d0a66dd05fb1b4613a',
                    'e7f5becff53e0782138492642b44afec74d53f17'
                  ],
                  branches: [],
                  tags: [],
                  author: {
                    name: 'jin-Pro',
                    email: '[email protected]'
                  },
                  authorDate: 'Sun Sep 4 13:54:20 2022 +0900',
                  committer: { name: 'GitHub', email: '[email protected]' },
                  committerDate: 'Sun Sep 4 13:54:20 2022 +0900',
                  message: 'Merge pull request 72 ...',
                },
                stemId: 'main'
              },
              {
                commit: {
                  sequence: 71,
                  id: 'fd46b07926bce8745ebe83d0a66dd05fb1b4613a',   // <<<<<  예시 커밋
                  parents: [
                    'd9483784b6b946ee6fb4e2c83f4b554c753ab632',
                    '3af7bc61a73bd044d5b9be7d8252ab3e21489284'
                  ],
                  branches: [],
                  tags: [],
                  author: {
                    name: 'Parksunghyeon',
                    email: '[email protected]'
                  },
                  authorDate: 'Sun Sep 4 01:24:24 2022 +0900',
                  committer: { name: 'GitHub', email: '[email protected]' },
                  committerDate: 'Sun Sep 4 01:24:24 2022 +0900',
                  message: 'Merge pull request 75 ...',
                },
                stemId: 'main'
              },
              // ...
            ]
          }
          // ...

문제 원인 파악

  • 현재 CSM 생성 로직에서 머지커밋을 식별하는 방법은 parents[1] 여부를 확인하는 것입니다.

  • 이는 squash 대상 내 머지커밋을 식별하는 방법으로도 사용되고 있습니다.
    image

  • 이 방식에서는 sub브랜치에서 main브랜치를 머지한 히스토리를 처리하지 못합니다.

    • 일반적으로는 main브랜치에서 sub브랜치를 머지하기때문에, parent[1] 이 sub브랜치를 가리키게 됩니다.
    • 하지만 sub브랜치에서 main브랜치를 머지한 경우에는, 해당 노드의 parent[1] 은 main브랜치를 가리키게 됩니다.
    • 위 상황을 현재 CSM생성로직을 동작시켜보면,
      1. main브랜치에서 CSMNode 를 만들면서 머지커밋을 확인해나감 << 이시점에서는 main브랜치 노드
      2. 머지커밋을 확인하면 parents[1] 로 타고올라가서 squash 대상을 추려냄 << 이시점에서는 sub브랜치 노드
      3. 추려낸 squash 대상들중 머지커밋이 있는지 확인함 <<< 이 시점에서 parnets[1]을 타고올라가면 main브랜치 노드
      4. 머지커밋이 없을때까지 2,3을 반복함
  • 3단계에서 순환참조(?)가 발생하여 해당시점 이하의 모든 커밋을 하나의 CSM-source 로 묶어버리게 됩니다.

TODO

  • squash 대상 내 머지커밋 식별 방법 변경 (단순 parents[1] 존재여부만 확인하는 것만으로는 부족)

[view] githru 전체적인 view 및 use case 정리

저번에 미팅을 하고나서 전반적으로 서로 구현하는 방향이 다 다르다고 느꼈습니다. 큰 틀이 없어서 그렇다고 느꼈는데요.
그래서 제가 먼저 githru가 전체적으로 어떻게 흘러가는지와 view에 대해서 구성해봤습니다. 기획자가 아니기도 하고 전문적인 툴도 다뤄본 경험이 적어서 keynote로 짜집기했습니다. 🫠

❤️‍🔥 본 내용은 전적으로 제 머릿속에서만 나온 내용이고, 구현하시는 분들 고생하시는데 이렇게 해라 저래라 할 의도가 아니며, 크로스 체크하기 위함임을 먼저 말씀드립니다. 고생해주셔서 감사합니다 ( _ _ )
❤️‍🔥 각 feature 위치 배치도 고려해서 배치했습니다. 디테일하게 피드백 부탁드립니다.
❤️‍🔥 이런 상황(use case 작성)을 위해서 쓸만한 툴은 없을까요? image와 번호 마킹, 텍스트로 전달하는게 너무 불편하네유. 어쩔수 없으려나요 ㅇㅅaㅇ...

처음 페이지에 진입하는 경우 보여지는 View

image

  • 1️⃣ 전체 기간을 대상으로 한 stem과 그에 따른 summary가 기본적으로 보여짐
    • summary는 각 클러스터가 갖고 있는 commit 리스트 전부 보여줌
  • 2️⃣ 클러스터가 클릭되지 않았을 때는 기본적으로 클러스터를 클릭해달라는 안내 문구가 보여짐

use case

image

  • 1️⃣혹은 2️⃣로 filter 함에 따라서 3️⃣이 업데이트 됩니다. 5️⃣와 6️⃣은 처음 페이지를 진입했을 때와 동일한 View를 보여줍니다.
  • 3️⃣ 스크롤이 가능합니다.
  • 4️⃣(cluster 리스트 중 하나)를 클릭하면 5️⃣와 6️⃣이 업데이트 됩니다.
  • 7️⃣(Filter)를 클릭하면 5️⃣가 업데이트 됩니다.
  • 6️⃣의 박스를 누르면, 줌인/줌아웃이 됩니다.
  • 8️⃣에 커서를 올리면, 프로필 사진 확대와 풀네임에 대한 tooltip이 나타납니다.
  • 9️⃣(summary 리스트 중 하나)을 클릭하면, 🔟이 나타납니다.

[engine] git log parser 회의 내용 공유_PR commit에 관하여

문제 상황

git log parsing 구현 준비 중에 있고, interface를 고민하고 있습니다.
commit 유형에는 일반/merge/PR이 있는데, 각 commit log의 형태가 달라 구성하는 interface도 달라집니다.

이때 PR commit의 경우는 다음과 같습니다.

commit <자기 자신 commit hash 값> <parent commit hash 값>
Author:     <Author 이름> <<Author email>>
AuthorDate: Thu Jul 28 11:52:16 2016 +0200
Commit:     <Commiter 이름> <<Commiter email>>
CommitDate: Thu Aug 4 12:42:55 2016 -0700

    <Commit 메시지>
    
    Fixes: <해결한 Issue URL>(항상 들어가진 않음)
    PR-URL: <PR의 URL>
    Refs: <관련 Issue URL>(항상 들어가진 않음)
    Reviewed-By: <Reviewer 이름> <<Reviewer email>>
    Reviewed-By: <Reviewer 이름> <<Reviewer email>>
    Reviewed-By: <Reviewer 이름> <<Reviewer email>>
    Reviewed-By: <Reviewer 이름> <<Reviewer email>>

<addition> <deletion> <directory>
13      1       src/node_contextify.cc
27      0       test/parallel/test-vm-strict-mode.js

질문

1. PR commit info

다른 commit과 다르게 [Fixes], [PR-URL], [Refs], [Reviewed-By]가 들어가는데,
현재 버전 상에서 commitlist에 해당 정보가 추가되어야할까요?

PR정보는 버전 0.2부터 적용이 된다고 했지만, view에서 PR정보를 작업을 할 때,
해당 commit이 아예 들어가지 않으면 적용할 수 있는 정보가 없을 것이라 예상됩니다.

특히나 오픈소스 레포지토리같은 경우 전부 PR commit으로만 구성되어 있는데,
예시 node
지금 버전 0.1에서 PR 정보를 완전히 제하고 넘기는 것이 맞을까요?

해당 질문은 view팀에서 답변해주시면 좋을 것 같습니다.

2. 유형 field 추가

PR이 추가되던 말던 일단 commit 유형이 두 개 이상(일반/merge/(PR))로 나뉘어지는데,
DAG 및 STEM, CSM 작업 시 commit 유형을 구분할 수 있는 field가 추가되면 좋을까요?

예시

{
    Type: "basic",
    commit: [
      "5d3f94e4072863b98dc17c3e43d77c98473bd42f",
      "224512334c9526a24ef49af030f93884102a4d2b",
    ],
    Author: "chaejung Kim",
    AuthorEmail: "[email protected]",
    AuthorDate: "Fri Jul 29 20:01:18 2022 +0900",
    Committer: "chaejung Kim <[email protected]>",
    CommitterEmail: "[email protected]",
    CommitDate: "Fri Jul 29 20:02:36 2022 +0900",
    message: "Feat: log to JSON function, parse01",
    fileChanged: [[Object]],
},

해당 질문은 DAG, STEM, CSM 담당하시는 분께서 답변해주시면 좋을 것 같습니다.

[view] summary 에서의 design space 설정

오늘 회의에서 @ytaek 님께서도 말씀해주셨다시피 0.2 버전을 대비하여
지금부터 얘기해보면 좋을 것 같아 우선 이슈부터 세웁니다.

고민했던 부분들과 답

  1. 데이터를 가공해서 시각화할 때 어떤 컬러 조합을 위주로 사용해야 하는가? -> 이 부분은 세미나에서도 얘기 나왔었던 것 같은데 그때 책을 언급해주셨던 것 같거든요 혹시 기억나시는 분이나 영택님께서 다시 알려주시면 해당 책 빠르게 읽고 저희에게 필요한 부분 요약해서 코멘트로 달겠습니다.
  2. 마지막 배열의 메시지를 보여주는 것도 좋지만 (임시적으로) 우선 키워드를 가지고 보여주는 것도 좋은 것 같아서 한 개의 클러스터에 있는 메시지의 맨 앞 단어만 가져와서 count 한 후에 가장 많이 나온 단어를 크기와 색깔로 구분하는 방식으로 가보는 건 어떨지?
  3. content 부분에서 커밋 메시지 키워드를 count하여 많이 나온 단어부터 보여주도록 하였는데 여기서 font size 등으로 style에 변화를 주는 것이 괜찮은 부분인지?
  4. 이전에는 아래 그림과 같이 author가 중복 제거 되지 않고 있어 많이 나오는 나머지 최대한 붙였습니다만
    image

user avatar(동그란거)가 겹쳐져 있는부분이 커서 구분이 안되니 최소한으로 붙이는게 좋아보입니당. (github도 아마 겹치는 부분 조금만 한듯)
아, 그리고 단어를 크기와 색깔로 구분하는 건 하지 않는 것이 좋겠습니다.
이미 user avatar에서 칼라 채널을 사용하고 있고,
여러가지가 들어가면 user가 읽기 힘들어져서요.
굳이 하고 싶다면 크기.. 정도인데, 작은 공간에서 크기차이가 주는게 얼마나 효용성이 있는지는 좀 볼필요가 있는데요

이런 의견이 있어서 프로필 이미지 간격 넓히고 키워드에서 색으로 구분하는 것은 제거했습니다.

와 같이 고민해보고 의견 구한 후 피드백에 맞춰 수정해보는 방식으로 현재 결과가 나왔습니다.

고민해보면 좋은 질문

by @ytaek

  1. 저 시각화 mark, channel을 왜 정했는지?
  2. 그리고 다른 것과 비교했을 때 이게 최선인지?

Feature List

Feature List
(추후에 API 까지 만들어야함)

  • Analysis-Engine
  • Crawling
  • Git log converter to structured data
  • Preprocessing
  • build Graph
  • Stemming
  • Clustering (? 이건 view에?)
  • View
  • Overview
  • Commit Detail
  • Interactions (events)
  • Vscode
  • webview loader
  • executor
  • LSP-style(or msg) communicator

[view] color code 통일 관련 논의

#74 PR에서 파생된 이슈입니다.

저희가 현재 결정된 color가 따로 없어서 각 컴포넌트 별로 선택하고 있는 color가 다른데요.
이 부분에 있어서 오프라인 미팅 때도 계속 언급이 되어 새로 Issue Main color와 Sub color를 정했으면 좋겠습니다.

현재 Bar chart 구현하며 vscode 익스텐션이라면 vscode 배경 색과 비슷해야 한다고 생각해 어둡게 바꿔놓았는데
전반적인 color code에 대해 함께 이야기해 통일하면 좋을 것 같습니다.

@jejecrunch 님 말씀으로는 우선 저희가 pallette가 있어서 이 pallette 기준으로 결정하면 좋을 것 같다고 하셨는데 저도 동의합니다.

결정해야 할 부분

  1. body background-color
  2. Main으로 쓸 theme color
  3. Main과 잘 어울리는 sub color 2~3가지
  4. font color

[view] : error npm run build:bundle

in .github/workflow/ci.yml

  • run: npm run build:all --if-present

this is throw an error


npm run build:all
=> [*:package.json] => "build:all": "npm run build --workspaces",
=> [view] "build:bundle": "webpack --config webpack.config.js",
=> error
=> Can't merge


We have to fix the error.

How to solve this error?

[engine] child_process spawn 방식 변경

Content

  • 현재 반영되어 있는 gitLogSpawn.ts의 함수의 경우 추가 설정 없이 child_process spawn만을 호출하고 있습니다. 해당 함수 호출은 로컬에서는 가능하지만 webview내부에서 접근하는 것과는 다르게 동작합니다. (추가 설정이 없는 경우 debug모드에서는 root에서 실행되는데, git 실행파일과 target git log를 특정할 수 없기 때문)

Coverage

  • parser.ts의 execSync로 구성된 함수를 변경
  • parseLog / parseSpawn를 deprecated 처리할지에 대한 의사결정 및 진행
  • vscode/extension.ts에서 git path와 repo path를 args로 parser.ts의 함수에 전달

FYI

[view] CLOC line chart height 밀리는 현상

데이터 통합하는 과정에서 발견한 현상입니다. summary에서 클릭했을 때 CLOC line chart height이 계속 밀리고 있습니다!
CLOC line chart 전체 div에서 height을 지정해주셔야할 것 같습니다 ... !

ezgif com-gif-maker (1)

[vscode] utils/git.util.ts 리버스 / 리 엔지니어링

Content

  • git-graph에서 부분 부분을 가져와 사용하고 있는 findGit 함수를 차후 생길 수 있는 라이선스 이슈를 피하기 위해서 리 엔지니어링을 진행합니다.
  • 진행간 더 좋은 방식이나 필요없는 부분에 대해서 판단 이후에 수정합니다.

Coverage

  • vscode/src/utils/git.util.ts의 함수 리팩토링을 진행

FYI

[Warning] The task 'npm: watch' cannot be tracked. Make sure to have a problem matcher defined

debugging을 위해 f5를 누르면 아래와 같은 에러가 발생합니다.

debug anyway 하면 되지만, 많이 거슬립니다.

원인은 문구에 적혀있는 것 처럼 problem matcher가 없다는 의미인데, tasks.json에 다음 두 problem matcher가 warning을 띄고있기 때문입니다.
image

각자가 아래 extension을 설치하는 것 말고는 마땅한 해결법을 찾지 못했습니다.
https://marketplace.visualstudio.com/items?itemName=amodio.tsl-problem-matcher

[view] Detail 구현

Detail

Render 조건

Vertical Cluster List Feature의 Summary Component를 클릭하는 경우 Detail Component가 렌더링 됩니다.

Props

{ data , id }

data : 전체 데이터

id : Click한 Summary ( Commit ) Id

Component UI

스크린샷 2022-09-03 오전 4 23 17

Component UI Data

diffStatistics => Statistics Component 렌더링

author => name => Summary Component 렌더링 , email 렌더 가능

authorDate => 렌더 가능

commitDate => 렌더 가능

committer => name,emails 렌더 가능

message => Summary Component 에서 렌더링

해당 STEM Cluster 의 COMMIT 나열 가능

희망

  • relation issue => 메세지에서 찾아야 하는가 ?
  • relation pr => url 가져올 수 있는가 ?
  • commit의 body 내용 가져올 수 있는가?

결과

스크린샷 2022-09-11 오후 1 35 57

[view] Summary author background-color 지정

관련 PR

#97

현 상황

전체적으로 파란계열이라고 임시적으로 컬러 계열을 정한 상황
author가 다른 클러스터에서도 같은 이름인데 다른 색이 나오는 경우가 있음

해야할 일

  • 컬러 계열에 맞춰 나오게 변경 -> 현 상황의 2번 문제도 해결 될 것 같음

[engine] 기준이 되는 branch name을 받아 main stem을 생성

as-is

  • 커밋의 브랜치 중 이름이 main/master인 것이 있다면, 그 커밋이 만드는 stem은 main stem이 됩니다.

to-be

  • stem 생성 시, 기준 branch의 이름을 받아 그 브랜치가 만드는 stem을 main stem으로 생성합니다.

githru prototype도 url 뒤에 파라미터로 기준이 되는 branch 이름을 받게 되어 있습니다.

            <Switch>
                <Route exact path="/" component = { Home }/>
                <Route path = "/v2/:repo/:releasePrefix/:mainStemBranchName" component = { v2 }/>
                <Route path = "/v2/:repo/:releasePrefix" component = { v2 }/>
                <Route path = "/v2/:repo/" component = { v2 }/>
            </Switch>

(지금보니 기준이 되는 branch 이름과, release prefix (v0.1.0이면 v)를 받아야 하는군요. 추후 반영이 필요하겠습니다 😄 )

나중에는 아래와 비스무리한 형태로 branch name을 user가 바꿔줄 수 있는 형태로 만들면 좋겠네요.
image

Originally posted by @ytaek in #140 (comment)

[engine] CommitRaw.branches에 경우에 따라 'HEAD' 포함되지 않음

  • HEAD가 가리키는 커밋을 어떤 브랜치가 포인팅하고 있을 때 -> commitRaw.branches에 HEAD 값이 포함되지 않습니다.
  • HEAD가 가리키는 커밋을 포인팅하는 브랜치가 없을 때 -> commitRaw.branches에 HEAD 값이 포함되어 있습니다.

HEAD 커밋의 브랜치 포인터 유무에 따라 CommitRaw.branches에 'HEAD' 값이 포함될지 여부가 달라지는 것 같습니다.
혹시나 의도된 것인지 궁금합니다! 의도되지 않았다면 branches에 HEAD도 포함되는 게 좋을 것 같아요.

(@blcklamb 님 확인 부탁드려요!)


  1. HEAD가 가리키는 커밋을 어떤 브랜치가 포인팅하고 있을 때
  • commit
commit a38625748a80945959ca5ff82555a60e8ac51186 9aca1fffa56dc46946f75a6573ed182d7f4c3837 (HEAD -> main, origin/main, origin/HEAD)
Author:     chaejung Kim <[email protected]>
AuthorDate: Sun Sep 4 20:17:59 2022 +0900
Commit:     chaejung Kim <[email protected]>
CommitDate: Sun Sep 4 20:17:59 2022 +0900

    commit message
  • result (branches에 HEAD가 포함되지 않음)
      {
        sequence: 0,
        id: 'a38625748a80945959ca5ff82555a60e8ac51186',
        parents: [ '9aca1fffa56dc46946f75a6573ed182d7f4c3837' ],
        branches: [ 'main', 'origin/main', 'origin/HEAD' ], // <<<---- 'HEAD' 포함 X
        tags: [],
        author: { name: 'chaejung Kim', email: '[email protected]' },
        authorDate: 2022-09-04T11:17:59.000Z,
        committer: { name: 'chaejung Kim', email: '[email protected]' },
        committerDate: 2022-09-04T11:17:59.000Z,
        message: 'feat(engine): sequenceNumber field add/n/n이후 DAG, STEM 작업을 위해 각 커밋의 순서를 나타내는 필드 추가',
        differenceStatistic: {
          totalInsertionCount: 0,
          totalDeletionCount: 0,
          fileDictionary: {}
        }
      }
  1. HEAD가 가리키는 커밋을 포인팅하는 브랜치가 없을 때
  • commit
commit a38625748a80945959ca5ff82555a60e8ac51186 9aca1fffa56dc46946f75a6573ed182d7f4c3837 (HEAD)
Author:     chaejung Kim <[email protected]>
AuthorDate: Sun Sep 4 20:17:59 2022 +0900
Commit:     chaejung Kim <[email protected]>
CommitDate: Sun Sep 4 20:17:59 2022 +0900

    commit message
  • result (branches에 HEAD가 포함됨)
      {
        sequence: 1,
        id: 'a38625748a80945959ca5ff82555a60e8ac51186',
        parents: [ '9aca1fffa56dc46946f75a6573ed182d7f4c3837' ],
        branches: [ 'HEAD' ], // <<<--- 'HEAD' 포함됨
        tags: [],
        author: { name: 'chaejung Kim', email: '[email protected]' },
        authorDate: 2022-09-04T11:17:59.000Z,
        committer: { name: 'chaejung Kim', email: '[email protected]' },
        committerDate: 2022-09-04T11:17:59.000Z,
        message: 'feat(engine): sequenceNumber field add/n/n이후 DAG, STEM 작업을 위해 각 커밋의 순서를 나타내는 필드 추가',
        differenceStatistic: {
          totalInsertionCount: 1,
          totalDeletionCount: NaN,
          fileDictionary: [Object]
        }
      }

[engine] function name convention 정의

Content

  • analysis-engine의 함수는 크게 두 양상을 가지고 있습니다.
    • get${Something}
    • build${Something}
    • build${Something}${ObjectType}
  • 정답이 있는 부분은 아니지만, 목적에 맞는 함수 명칭을 사용하는 것으로 획일된 개발 프로세스를 가져갈 수 있고 유지보수에 도움이 됩니다.
  • 명명 사전을 만들어야 한다면 wiki에 추가적으로 진행합니다.

Coverage

  • analysis-engine의 함수 명칭에 대해 국한합니다. 외부의 함수 그리고 변수와 같은 부분은 논외 대상입니다.

FYI

Remarks

  • 진행을 원하시는 분은 저에게 DM을 주시면 감사하겠습니다. 자료 작성을 같이 해보면 좋을 것 같네요.

[engine] stem.spec.ts 수정

Contents

  • parser의 작업이 upstream/main에 머지가 된 것에 따라서 sequence관련 항목을 update할 필요성이 생겼습니다.

Coverage

  • 시퀀스에 맞게 (가장 최근의 commit이 0) 0으로 고정되어 있는 값을 수정
  • 현재 반대 순번으로 표현하고 있는 FakeCommitData를 역순으로 다시 작성

FYI

[FIX REQUEST] Statistics

아래 항목들에 대해서 살펴봐주시고, 담당하시는 분들께서는 comment로 진행사항을 알려주세요~.

각 항목에 대해서 PR 올려주셔서 바로 반영해주시면 되고,
혹시 9/14일 전에 빠르게 수정이 불가능한 경우라면, 항목별로 '추후 수정 예정'이라고 댓글로 달아주세요~.

image

  • 1. 윗쪽 select box에서 commitcommit #로 바꿔주세요.
  • 2. select box의 테두리만 굵은데 나머지와 통일성 있게 바꿔주시고,
  • 3. select box 위치를 오른쪽 위로 바꿔주세요.
  • 4. select box와 chart, 아래 축 정보의 margin을 줄여주세요.
  • 5. y축의 tick은 없어도 되겠습니다.

image

  • 6. y축 값이 지금은 commit # / Total commit# 의 백분율인데, 이럴 경우 현재처럼 차트의 반 이상이 비어 있게 됩니다 (dominant한 contributor가 있지 않는 이상). 100%를 max로 잡지말고 최대값+a를 max로 잡거나, 혹은 그냥 cardinality (commit#)만 가지고 표시하면 더 보기 좋을 것 같습니다. (추후에 값의 분포에 따라서 top 10 user만 보여준다던지, Percentage가 서로 비슷할 경우, 다를 경우를 분리해서 보여주는 값을 다르게 한다던지 하는 방법도 있겠네요)

  • 7. bar chart를 나중에 avatar 정보를 긁어오게 된다면, 아래 GitHub처럼 horizontal로 해도 괜찮겠네요 ㅎㅎ (지금은 item의 이름이 길어 horizontal로 하긴 했습니다.)

image

[FIX REQUEST] Temporal Filter

아래 항목들에 대해서 살펴봐주시고, 담당하시는 분들께서는 comment로 진행사항을 알려주세요~.

각 항목에 대해서 PR 올려주셔서 바로 반영해주시면 되고,
혹시 14일 전에 빠르게 수정이 불가능한 경우라면, 항목별로 '추후 수정 예정'이라고 댓글로 달아주세요.

  • 브러싱은 안되더라도, 날짜로 Filter를 하면 Line chart도 같이 바뀌어야 하는데 안 바뀝니다.

image

  • Bar chart -> Line Chart로 변경 (#107 아래쪽에 제 리뷰 사항들 다시 봐주세요)
  • Temporal Filter높이를 아래 위 전부 합쳐서 margin 빼고 100120px 정도로 만들어주세요. (지금 margin을 합치면 280px 이 넘습니다). 아래 그림이 margin 빼고 100120px 이 되도록 입니다.

image

  • Chart 제목 붙여주세요. (#129)

image

  • #165
  • y축 값들은 겹쳐지는 부분도 있고 색이 명확하게 안보이는데, 그냥 빼주셔도 될 것 같습니다.

image

  • 혹시 오른쪽에 checkbox는 어떤 내용일까요? spec에 없는 부분은 빼주시면 감사하겠습니다.

image

[FIX REQUEST] Graph + Detail

아래 항목들에 대해서 살펴봐주시고, 담당하시는 분들께서는 comment로 진행사항을 알려주세요~.

각 항목에 대해서 PR 올려주셔서 바로 반영해주시면 되고,
혹시 9/14일 전에 빠르게 수정이 불가능한 경우라면, 항목별로 '추후 수정 예정'이라고 댓글로 달아주세요~.

image

  • #148

  • #149

  • Node(Cluster)별 높이를 조금 더 줄여서 많은 정보가 보이게 하면 좋겠습니다. 지금은 여백이 좀 많아서 한 페이지에 10개 미만으로 보이네요. IDE에서는 아랫쪽에 problem matcher나 terminal 등이 떠서 실제 보이는 정보들을 훨씬 줄어듭니다.

image

  • 윗 node와 아래 node가 서로 연결된 느낌이 없어서, node와 node사이에 link (수직선?)을 넣어주던지, 혹은 아예 테이블 형태처럼 붙여주세요. 서로 이어져서 ordering되었다는 인식이 되어야 합니다.
  • �node 색깔도 조금 명확하게 바꾸는게 좋겠습니다. 어두운 바탕이라 그런지 잘 안보이네요.
  • node의 width도 지금 100이 넘는데, 50~70 정도로 줄이면 좋겠습니다. (높이가 줄어들테니 뚱뚱하게 보이지는 않을 듯)
  • GitHub에서 가져온 부분이긴 하지만, 불필요하게 서술(문장)형으로 적혀있는 것 같습니다. 필요한 부분만 골라내서 컴팩트하게 바꾸면 좋겠네요. 한 줄 정도로. (추후에는 glyph나 작은 chart 정도로 표현해도 괜찮겠습니다)

image

  • user avatar에 hover를 했을 때 나오는 설명이 avatar동그라미와 좀 떨어져있습니다. 가까이 붙여주시면 감사하겠습니다. (tooltip의 크기, margin을 좀 줄여도 괜찮겠습니다)

image

  • node를 클릭했을 때, 고정 height 로 나오는 것 같은데, 아래와 같은 경우 graph 아래쪽이 잘린 것 같은 느낌을 주네요. 변동폭으로 하면 좋겠습니다.

image

  • node가 collapse되었는지 아닌지에 대한 표시가 필요합니다. 바로 윗 그림에서 그런게 없으니 더 이상했었던 것 같네요.
  • detail에는 commit별로 commit ID, 날짜와 author 정보도 같이 있는게 좋겠습니다.

[view] contents 추가

commit message의 앞 keyword만 딴 것은 좋긴 했는데, 처음 list가 보일 때 화면을 채워주는 contents 가 좀 없어보이네요 ㅜ.ㅜ 일단 마지막 commit message으로 채워놓는것이 좋을 것 같아요. (혹은 feat(webview): add typescript structure + 2 more 정도로 표시하던지)

[engine] Commit DAG 구현

Input

  • Commit List

Output

  • 모든 Commit Node를 담고 있는 객체 (Map or Array?)

Todo

  • Commit으로 CommitNode를 생성
  • 생성된 CommitNode를 모두 관리하는 객체 생성

[Discussion] Apply getboundingclientrect chart component

차트 컴포넌트의 width와 height를 상위 div(wrapper)의 width와 height를 가져와서 설정하되, css로 상위 div를 조작하여 사용하는 것이 좋을 것 같습니다.

차후 수정시 css만 수정하여 차트를 바꿀 수 있습니다.

[view] Change Bar Chart to Line Chart in TemporalFilter Component

Description

trend를 알고 싶다는 목적을 위해서 Bar chart를 Line Chart로 변경

  • #145 의 '추후 수정 예정' 부분입니다

Task

  • Bar Chart를 Line Chart로 변경
  • y축 오른쪽 배치 -> 왼쪽 배치 변경
  • x축 날짜 표시 조금 더 디테일 하게 변경
  • styles: 아랫쪽을 더 쳐다보도록 회색 계정 컬러 + 톤다운
  • brushing 기능 추가에 따른 filtered in 된 부분에 main color 하이라이트 (dependency on #164)

[engine] branch 정보 누락 문제

관련 상세 정보 및 PR

문제 상황

terminal에 직접 git --no-pager log --all --parents --numstat --date-order --pretty=fuller -c 실행 시 branch 정보가 뜨는데,
image

[packages/analysis-engine/src/parseSpawn.ts]에서 실행되는 spawn으로 받아온 데이터에서는 branch가 누락되어 전달됩니다.
image

  • terminal에서 실행하는 git version과 spawn시 실행하는 git version은 동일합니다.

예상 원인

spawn에서 데이터를 받아서 가공하는 방식 또는 데이터를 받는 것 자체에서 문제가 생기는 것 같은데, 아직 제대로된 원인을 파악하지 못했습니다.

[view] Statistics - Author Bar chart 구현 (v0.1.0)

Description

imageimage

  • 전체 혹은 선택된 기간 내 author 데이터에 대한 bar chart 구현
    • author 별 commit, total files changed, total insertions, total deletions 수치 및 순위
    • 기존 githru compare의 files의 chart 참고

Task

  • 선택된 Cluster 데이터를 author 기준으로 받도록 가공
  • Bar chart 구현
  • metric 변경 시 인터렉션 구현

react18 버전에서 `ReactDOM.render` 대신 `createRoot` 를 사용하라는 변경 사항이 있는데 저희 프로젝트에 react 18버전으로 올라와 있길래 참고하면 좋을 것 같아 리뷰드립니다~

react18 버전에서 ReactDOM.render 대신 createRoot 를 사용하라는 변경 사항이 있는데 저희 프로젝트에 react 18버전으로 올라와 있길래 참고하면 좋을 것 같아 리뷰드립니다~

cf. https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#updates-to-client-rendering-apis

Originally posted by @hanseul-lee in #2 (comment)

[view] Apply Brush Feature to TemporalFilter Component

Description

릴리즈 일정을 위해 Temporal Filter의 구간 설정을 기간 설정(input date)으로 적용 했었음. 해당 부분을 Brush로 기간을 선택할 수 있도록 변경

Task

  • Brush 기능 구현
  • Brush로 Line Chart 구간 선택에 따른 날짜 연결 기능
  • 날짜에 따른 Filtering 기능 구현

[View] The message property does not exist in the commit type.

export type Commit = {
  id: string;
  parentIds: string[];
  author: GitHubUser;
  committer: GitHubUser;
  authorDate: Date;
  commitDate: Date;
  diffStatistics: DiffStatistics;

  // fill necessary properties...
};
// commit data
commit
ㄴ id : "2a7a93cde9c9f74d5f05c1d0fb1da8e96da7057b"
ㄴ parentIds :  ['7d8569355a24bf79c84c2970f88a62c20261c3f5']
ㄴ author : {names: Array(1), emails: Array(1)}
ㄴ committer : {names: Array(1), emails: Array(1)}
ㄴ authorDate : "2018-09-13T07:30:42.000Z"
ㄴ commitDate : "2018-09-13T07:30:42.000Z"
ㄴ diffStatistics : {insertions: 0, deletions: 196, files: {…}}
ㄴ message : "WIP"

Commit Type에 Message Property를 추가하고자 합니다.

[Question] Cluster Data Ordering

Ordering 관련해서 질문드립니다 !

현재 VerticalClusterList 팀에서는 따로 reverse 하지 않고 fake asset을 그대로 사용 중인데, engine 팀에서 내려 받는 데이터의 경우 최신 순으로 정렬되어 내려져 오는 지 궁금합니다 !

이미 언급된 내용이라면 죄송합니다

[engine] parser.spec.ts 작성

Content

  • #28 가 close처리되어 있어서 새로 작성했습니다.
  • parser에 대한 test 파일을 작성합니다.

Coverage

  • node 내장함수인 child_process에 대한 함수 mocking 처리가 필요

FYI

Changelog

  • branches / tags를 commit관련 정보에서 뽑아내는 로직이 존재합니다. 해당 부분에 대한 테스트도 포함합니다.

[Question] CSM 과 Cluster

Githru 질문

Cluster , STEM, CSM 에 대한 이해도 부족으로 인한 질문입니다.

제 생각

[ CSM-base commit 질문 ]

위 이미지 (d)에서 Main STEM의 5,6번째 commit은 merge commit으로 CSM-base commit이며
위 이미지 (d)에서 fix STEM의 첫번째 commit은 merge commit이 아니지만, dev STEM의 5번째 commit을 가장 먼저 포함하고있는 commit이라 fix STEM의 첫번째 commit이 CSM-base commit이 된다.

라고 이해했는데 맞을까요???

[ Cluster 질문 ]
위 이미지 (g)에서
main STEM에서 각각 3개/3개/2개의 commit을 묶어서 3개의 Cluster를 만들었는데,

제 생각은 (g)에서 main STEM의 붙어있는 2개의 Cluster ( CSM-base commit이 없는 Cluster와 있는 cluster)가 하나의 Cluster로 형성될거라 생각했습니다.

Cluster 형성 기준이 무엇인지 이해가 가질 않아 질문드리게 되었습니다!

@ytaek

[view] vscode 테마 컬러 가져오기 및 git lens 분석 내용 공유

vscode theme color에 접근하는 방법 및 githru에 적용 관련해서 리서치를 했습니다. 그래서 아래 gitlens처럼 vscode theme 컬러가 달라질 때, 아래 gitlens+의 CommitGraph와 Visual File History 처럼 배경화면색도 그에 맞게 변하는 기능을 구현하려는게 목적이었는데요.

commit graph

vscode api로는 theme color에 마땅히 접근할 방법이 없었습니다. onDidChangeActiveThemeColor api가 있지만 접근해서 뭘 하기 유의미한 데이터를 제공하지 않습니다.

onDidChangeActiveThemeColor api에 대해서 조금 설명을 드리면, 호출시 이벤트 핸들러의 인자로 kind 프로퍼티가 오는데, kind에 할당되는 숫자가 theme의 변경에 따라서 바뀌지만, 몇몇 theme은 같은 숫자를 공유하기 때문에 의미가 없습니다.

image

그래서 어제 오늘 git lens를 분해해봤는데요. 앞서 말한 CommitGraph와 Visual File History를 생성할 때 document.body에 Mutation Observer를 등록해서 컬러를 업데이트 하고있습니다.(코드는 맨 아래에 있스빈다) 이를 저희쪽에서 이용한다면 아래와 같이 코드를 작성할 수 있습니다.

<!DOCTYPE html>
<html lang="en">
    <head>
	// 생략
   </head>
    <body>
        <div id="root">
        <script src="${reactAppUri}"></script>
        <script>
            const callback = () => {
                const computedStyles = window.getComputedStyle(document.body);
                console.log(computedStyles.getPropertyValue('--vscode-font-weight')); // 배경 theme color를 가져옴
            }

            const observer = new MutationObserver(callback);

            observer.observe(document.body, { attributes: true, attributeFilter: ['class'] });
        </script>
    </body>
</html>

테마를 바꿀때 출력되는 gif를 보면 아래와 같습니다. 웹뷰를 띄우고 개발자 도구( command + Option + i)에서 콘솔을 찍은 것 입니다.

getPropertyValue로 가져올 수 있는 vscode theme color들은 다음과 같습니다.

git lens에서는 아래와 같이 몇 가지 vscode theme color를 가져와서 자신들이 제공하는 feature가 vscode theme과 잘 녹아들게 하는 것 같습니다. (실제로 어디에, 어떻게 적용되는지는 모르겠습니다. 로컬에서 git lens extension 코드를 돌려도 프리미엄인 commit graph 나 file history view에는 접근할 수가 없어요. ㅜ_ㅜ)

그런데 아래 gif처럼, 단순히 background-color: transparent로 두어도 정상적으로 theme color가 반영이 되기 때문에, git lens처럼 컬러를 섬세하게 표현하고 검토해야하는 상황이 못된다면 background-color를 transparent하게 두는게 좋을 것 같습니다.

transparent

git lens 분석 내용 공유

git lens 파일을 조금 까본 내용을 공유드립니다. 아마 누군가는 git lens를 볼 일이 있을 것 같아서요. 조금이라도 삽질을 줄이셨으면 하는 마음에서...

  1. git lens는 저희와는 다르게 YeomanVscode Extension Generator를 이용하지 않고, 밑바닥부터 환경을 구성한 것 같습니다.

  2. commit graph와 file history view 렌더링 관련 코드를 위치 ( src/webview/apps/plus)

graph.ts 내부에서 graph.html 내부의 전체적인 상태와 마크업을 GraphWrapper가 그려주어 commit graph를 보여주고, timeline.ts 내부에서 timeline.html 내부의 전체적인 상태와 마크업을 chart.ts가 그려주어 Time Line(File History View)을 렌더링합니다. 화면에 보여지는 것은 왠만해선 이 폴더에서 다루어집니다.

  1. 화면에 보여지는 것 이외에, 웹뷰를 띄우거나 닫는 것 혹은 vscode와의 통신은 아래 폴더에서 다루어집니다. (src/plus/webviews)

  1. grpah.ts 내부 클래스는 appBase.ts를 상속받고, appBase.ts 내부에서 MutationObserver를 등록하는 함수(initilalizeAndWatchThemeColor)를 호출합니다. initilalizeAndWatchThemeColor 함수는 theme.ts 파일에 존재합니다. MutationObserver를 등록하는 풀 코드는 아래와 같습니다.
/*global window document MutationObserver*/
import { darken, lighten, opacity } from './colors';

// here : theme changed
export function initializeAndWatchThemeColors(callback?: () => void) {
	const onColorThemeChanged = () => {
		const body = document.body;
		const computedStyle = window.getComputedStyle(body);

		const isLightTheme =
			body.classList.contains('vscode-light') || body.classList.contains('vscode-high-contrast-light');
		// const isHighContrastTheme = body.classList.contains('vscode-high-contrast');

		const bodyStyle = body.style;

		bodyStyle.setProperty('--font-family', computedStyle.getPropertyValue('--vscode-font-family').trim());
		bodyStyle.setProperty('--font-size', computedStyle.getPropertyValue('--vscode-font-size').trim());
		bodyStyle.setProperty('--font-weight', computedStyle.getPropertyValue('--vscode-font-weight').trim());

		bodyStyle.setProperty(
			'--editor-font-family',
			computedStyle.getPropertyValue('--vscode-editor-font-family').trim(),
		);
		bodyStyle.setProperty('--editor-font-size', computedStyle.getPropertyValue('--vscode-editor-font-size').trim());
		bodyStyle.setProperty(
			'--editor-font-weight',
			computedStyle.getPropertyValue('--vscode-editor-font-weight').trim(),
		);

		const backgroundColor = computedStyle.getPropertyValue('--vscode-editor-background').trim();

		let color = backgroundColor;
		bodyStyle.setProperty('--color-background', color);
		bodyStyle.setProperty('--color-background--lighten-05', lighten(color, 5));
		bodyStyle.setProperty('--color-background--darken-05', darken(color, 5));
		bodyStyle.setProperty('--color-background--lighten-075', lighten(color, 7.5));
		bodyStyle.setProperty('--color-background--darken-075', darken(color, 7.5));
		bodyStyle.setProperty('--color-background--lighten-10', lighten(color, 10));
		bodyStyle.setProperty('--color-background--darken-10', darken(color, 10));
		bodyStyle.setProperty('--color-background--lighten-15', lighten(color, 15));
		bodyStyle.setProperty('--color-background--darken-15', darken(color, 15));
		bodyStyle.setProperty('--color-background--lighten-30', lighten(color, 30));
		bodyStyle.setProperty('--color-background--darken-30', darken(color, 30));
		bodyStyle.setProperty('--color-background--lighten-50', lighten(color, 50));
		bodyStyle.setProperty('--color-background--darken-50', darken(color, 50));

		color = computedStyle.getPropertyValue('--vscode-button-background').trim();
		bodyStyle.setProperty('--color-button-background', color);
		bodyStyle.setProperty('--color-button-background--darken-30', darken(color, 30));
		bodyStyle.setProperty('--color-highlight', color);
		bodyStyle.setProperty('--color-highlight--75', opacity(color, 75));
		bodyStyle.setProperty('--color-highlight--50', opacity(color, 50));
		bodyStyle.setProperty('--color-highlight--25', opacity(color, 25));

		color = computedStyle.getPropertyValue('--vscode-button-secondaryBackground').trim();
		bodyStyle.setProperty('--color-button-secondary-background', color);
		bodyStyle.setProperty('--color-button-secondary-background--darken-30', darken(color, 30));

		color = computedStyle.getPropertyValue('--vscode-button-foreground').trim();
		bodyStyle.setProperty('--color-button-foreground', color);

		let foregroundColor = computedStyle.getPropertyValue('--vscode-editor-foreground').trim();
		if (!foregroundColor) {
			foregroundColor = computedStyle.getPropertyValue('--vscode-foreground').trim();
		}
		bodyStyle.setProperty('--color-foreground', foregroundColor);
		bodyStyle.setProperty('--color-foreground--85', opacity(foregroundColor, 85));
		bodyStyle.setProperty('--color-foreground--75', opacity(foregroundColor, 75));
		bodyStyle.setProperty('--color-foreground--65', opacity(foregroundColor, 65));
		bodyStyle.setProperty('--color-foreground--50', opacity(foregroundColor, 50));

		color = computedStyle.getPropertyValue('--vscode-focusBorder').trim();
		bodyStyle.setProperty('--color-focus-border', color);

		color = computedStyle.getPropertyValue('--vscode-textLink-foreground').trim();
		bodyStyle.setProperty('--color-link-foreground', color);
		bodyStyle.setProperty('--color-link-foreground--darken-20', darken(color, 20));
		bodyStyle.setProperty('--color-link-foreground--lighten-20', lighten(color, 20));

		color = computedStyle.getPropertyValue('--vscode-sideBar-background').trim();
		bodyStyle.setProperty('--color-view-background', color || backgroundColor);

		color = computedStyle.getPropertyValue('--vscode-sideBar-foreground').trim();
		bodyStyle.setProperty('--color-view-foreground', color || foregroundColor);

		bodyStyle.setProperty(
			'--color-view-header-foreground',
			computedStyle.getPropertyValue('--vscode-sideBarSectionHeader-foreground').trim() ||
				color ||
				foregroundColor,
		);

		color = computedStyle.getPropertyValue('--vscode-editorHoverWidget-background').trim();
		bodyStyle.setProperty('--color-hover-background', color);
		color = computedStyle.getPropertyValue('--vscode-editorHoverWidget-border').trim();
		bodyStyle.setProperty('--color-hover-border', color);
		color = computedStyle.getPropertyValue('--vscode-editorHoverWidget-foreground').trim();
		bodyStyle.setProperty('--color-hover-foreground', color);
		color = computedStyle.getPropertyValue('--vscode-editorHoverWidget-statusBarBackground').trim();
		bodyStyle.setProperty('--color-hover-statusBarBackground', color);

		// graph-specific colors
		bodyStyle.setProperty(
			'--graph-panel-bg',
			isLightTheme ? darken(backgroundColor, 5) : lighten(backgroundColor, 5),
		);
		bodyStyle.setProperty('--graph-theme-opacity-factor', isLightTheme ? '0.5' : '1');

		// alert colors
		color = computedStyle.getPropertyValue('--vscode-inputValidation-infoBackground').trim();
		bodyStyle.setProperty('--color-alert-infoHoverBackground', isLightTheme ? darken(color, 5) : lighten(color, 5));
		bodyStyle.setProperty('--color-alert-infoBackground', color);
		color = computedStyle.getPropertyValue('--vscode-inputValidation-warningBackground').trim();
		bodyStyle.setProperty(
			'--color-alert-warningHoverBackground',
			isLightTheme ? darken(color, 5) : lighten(color, 5),
		);
		bodyStyle.setProperty('--color-alert-warningBackground', color);
		color = computedStyle.getPropertyValue('--vscode-inputValidation-errorBackground').trim();
		bodyStyle.setProperty(
			'--color-alert-errorHoverBackground',
			isLightTheme ? darken(color, 5) : lighten(color, 5),
		);
		bodyStyle.setProperty('--color-alert-errorBackground', color);
		color = isLightTheme ? darken(backgroundColor, 5) : lighten(backgroundColor, 5);
		bodyStyle.setProperty(
			'--color-alert-neutralHoverBackground',
			isLightTheme ? darken(color, 5) : lighten(color, 5),
		);
		bodyStyle.setProperty('--color-alert-neutralBackground', color);
		bodyStyle.setProperty('--color-alert-infoBorder', 'var(--vscode-inputValidation-infoBorder)');
		bodyStyle.setProperty('--color-alert-warningBorder', 'var(--vscode-inputValidation-warningBorder)');
		bodyStyle.setProperty('--color-alert-errorBorder', 'var(--vscode-inputValidation-errorBorder)');
		bodyStyle.setProperty('--color-alert-neutralBorder', 'var(--vscode-input-foreground)');
		bodyStyle.setProperty('--color-alert-foreground', 'var(--vscode-input-foreground)');

		callback?.();
	};

	const observer = new MutationObserver(onColorThemeChanged);

	observer.observe(document.body, { attributes: true, attributeFilter: ['class'] });

	onColorThemeChanged();
	return observer;
}

[engine]git log parser test code 구현

Task

  • test code 세팅 --jest 이슈도 생각해보기
  • json mock data 작성하기 (될수 있는한 다양한 사례로)
  • 백슬레시도 문자열로 고려될수 있는지 찾아보기
export const exampleLog01 = `
commit df463687612482d66f0ed9d938aef279dba2a19c faea5b2adfb1376ef22f1cb45e9e827cd2618221
Author:     Josh Gross <[email protected]>
AuthorDate: Thu Jan 6 14:39:07 2022 -0500
Commit:     Josh Gross <[email protected]>
CommitDate: Thu Jan 6 14:39:07 2022 -0500

    Use \`jonabc/setup-licensed\` in Licensed workflow

6       6       .github/workflows/licensed.yml
`

(draft) implementation STEM

(draft) STEM 구현 관련 내용정리


STEM 알고리즘..?

  1. 가장 마지막 커밋에서부터 parent 가 1개인것 따라올라감
  2. 분기커밋은 지나간다음 감지해서 1번 반복

※ checkpoint : "가장 마지막 커밋부터" "parent 따라올라감"


고려사항

  • STEM 을 왜 만드는것인가..? 어디에 사용되는가..?
    • CSM 을 만들때 사용함
      1. 머지커밋을 감지
      2. 현재STEM을 제외한 merge-parent 순회

※ checkpoint : "현재 STEM을 제외"

  • 새로운 자료(CommitStem)를 만들것인가..?
    기존 자료(CommitRaw)에 마킹할것인가..?

  • CommitStem 사용..?

    • 메모리x2 사용
    • 순회가 편한가..?
    • 나중에 CSM만들때 찾기가 편할까..?
  • CommitRaw 마킹..?

    • 메모리 그대로
    • 역방향순회 필요
    • 나중에 CSM만들떄 찾기가 편할까..?
  • CSM만들때, 현재커밋이 현재STEM인지 아닌지
    어떻게 편하게 알도록 할수있을까?

    • dictionary 를 만든다..?
    • 기존 CommitRaw[] 에 마킹해놓고,
      DAG를 그 다음에 만들면..?
    • 어차피 CSM은 DAG를 보고 만드니깐..
      STEM 정보가 DAG에 포함되어있어야..?
start!
DAG(stemA)    →   DAG(stemA)    →   DAG(stemA)
      └→   DAG(stemB)    →    DAG(stemB)


DAG(stemA)    ←   DAG(stemA)    ←   DAG(stemA)  <<< start!
       ↖   DAG(stemB)    ←    DAG(stemB)  <<< start!

자료 정의

CommitRaw

  • id: Hash
  • parent: Hash[] (max length 2)
  • ...

CommitStem

  • id: Hash
  • next: Hash

CommitStem 사용하는 경우..

const stemA: CommitStem = { id, next };
stemA.append( ... )
stemA.append( ... )
stemA.append( ... )

const stemB: CommitStem = { id, next };
stemB.append( ... )
stemB.append( ... )
stemB.append( ... )

const stems: CommitStem[] = [
  stemA, stemB,
]
stemA    ←   stemA  ←  stemA
      ↖  stemB           ←            stemB

CommitRaw 에 마킹하는 경우...

raw[0] ← raw[1] ← raw[2] ← raw[3] ← raw[4]
   A            B             A              A            B  

구현1

  • input : DAG
  • output : CommitStem[]
  1. 리프노드를 찾는다

    • top-down DAG 일경우, 최초커밋 or 고아커밋 (n개가 될수있음)
    • bottom-up DAG 일경우, 마지막커밋 (n개가 될수있음)
  2. 노드의 parent 를 찾는다

    • parent 1개 : 일반커밋. parent[0] 으로 넘어감 (마킹)
    • parent 2개 : 머지커밋. parent[0] 으로 넘어감 (마킹) + parent[1] 으로 넘어감 (재귀호출)
    • parent 0개 : 마지막커밋. 종료
  3. 순회한 노드의 parent 가 0 일때까지 2) 를 반복한다


구현2

  • input : CommitRaw[]
  • output : CommitStem[]
  1. 가장 마지막커밋을 찾는다

    • 시간순으로 정렬되어있는 CommitRaw[] 를 뒤에서부터 순회
  2. 순회한 CommitRaw 별로 parent 를 확인한다

    • parent 1개 : 일반커밋. parent[0] 으로 넘어감 (마킹)
    • parent 2개 : 머지커밋. parent[0] 으로 넘어감 (마킹) + parent[1] 으로 넘어감 (재귀호출)
    • parent 0개 : 최초커밋 or 고아커밋. 종료
  3. 순회한 CommitRaw 이 parent 0 일때까지 2) 를 반복한다

  • CommitRaw[0] 에 도달하면 종료

[engine] git metadata(git log)를 parsing 하여 commitList 만들기

git log 명령어를 입력했을 때 나오는 정보를 json 형태로 parsing

input

git log 명령어를 입력했을 때 나오는 정보

output

{
    commit: [
      "5d3f94e4072863b98dc17c3e43d77c98473bd42f",
      "224512334c9526a24ef49af030f93884102a4d2b",
    ],
    Author: "chaejung Kim",
    AuthorEmail: "[email protected]",
    AuthorDate: "Fri Jul 29 20:01:18 2022 +0900",
    Committer: "chaejung Kim <[email protected]>",
    CommitterEmail: "[email protected]",
    CommitDate: "Fri Jul 29 20:02:36 2022 +0900",
    message: "Feat: log to JSON function, parse01",
    fileChanged: [[Object]],
  },

TODO

  1. git log 에서 필요한 정보가 무엇인지 생각해보기, commitList interface 만들기
  2. 1이 정해지면 이 정보를 json 형태로 구성하기
  3. commitList 를 return 하는 함수 만들기

[view] Vertical Cluster List

Description

image

  • Collapsable Graph by @vgihan
    image
    위 이미지를 수직으로 변형하여 적용

  • Profile & Summary by @jejecrunch
    image

Question

1. 수직축 길이 어떻게 변형되게 만들건지?
2. 프로필 이미지가 들어가는 게 맞는지?
3. Summary 내용에는 어떤 키워드가 들어가고 엔진 팀에서 어떻게 건네주는지?

Task

  • Collasable Graph 구현
  • Profile & Summary 구현

[view] Add Functions for Changing String type to Date type

Description

  • 상황 : Line Chart를 그릴 때, Date type이 필요함
  • 논의한 PR 링크 : #130
  • JSON.stringfy하는 처리가 필수불가결한 상황이기에 engine에서 Date type으로 넘겨주는 건 불가능
  • 현재 구현 상태: Line Chart(=Bar Chart) 컴포넌트에서 new Date로 직접 가공하고 있음
  • 논의 결과: Line Chart를 그리기 위한 sort하는 함수에서 Date type으로 변환해서 전달

Tasks

  • Line Chart를 그리기 위한 sort하는 함수에 Date type으로 변환하는 부분 추가

[engine] CSM 구현

Purpose

  • 나는 클러스터링을 진행할 개발자입니다.
  • 나는 STEM에 의거해 압축된 DAG를 보고 싶습니다.
  • 그래서 보다 더 가시적인 데이터를 제공할 수 있습니다.

Content

  • DAG를 데이터로 받아서 압축된 Branch List를 반환합니다.
    • input) DAG
    • output) Squashed DAG
  • Branch List를 순회하면서 다음과 같은 기준에 의거해서 Squash Merge를 진행합니다.
    • !Main Stem
    • !MergedTraversed
    • 해당 Node가 root Node의 implicit branch number와 같지 않은 경우

Coverage

  • corpus, tiff, release 관련 부분은 제외합니다.
  • ImplicitBranch 관련 항목은 협의를 통해 해당 feature에서 진행하거나 추가 feature로 진행합니다.

FYI

[engine] STEM 구현

STEM 개요

  • 부모가 동일한 커밋을 한 줄로 보여준다

STEM 목적

  • CSM 생성시,
    • 현재커밋과 분기커밋의 STEM 동일여부 확인
  • CSM 클러스터링시,
    • 인접 CSM을 가져올때, 동일STEM 내 CSM 들을 가져옴

인터페이스

  • input : CommitDAG
  • output : CommitDAG (with STEM)

todo

  • 모든 DAG 구성요소에 STEM 마킹

CSM (엔진팀 output) → ClusterNode[] (view팀 input) 매핑처리 관련 논의

CSM (엔진팀 output) → ClusterNode[] (view팀 input) 관련 질문입니다.

아래는 CSM PR 내 코멘트 에서 논의했던 CSM 인터페이스 관련 내용입니다.

csm-source : squash 된 모든 커밋들 (기준커밋 포함)
csm-base : csm-source 를 포함하는 상위 개념

vs

csm-source : squash 된 커밋들 (기준커밋 제외)
csm-base : 기준커밋

여기에서 후자(csm-source 와 csm-base 를 구분) 방향으로 작업 진행했는데요.
view팀에서 사용하고있는 ClusterNode[] 는 전자(csm-source 와 csm-base 를 구분하지않음) 형식 같아서요.

CSM → ClusterNode[] 매핑작업 할때, csm-base 를 식별하지않고 합쳐버려도 괜찮을지 궁금합니다.

[view] color 선정

#74 PR에서 파생된 이슈입니다.

저희가 현재 결정된 color가 따로 없어서 각 컴포넌트 별로 선택하고 있는 color가 다른데요.
이 부분에 있어서 오프라인 미팅 때도 계속 언급이 되어 새로 Issue Main color와 Sub color를 정했으면 좋겠습니다.

개인적으로 우선 저희가 pallette가 있어서 이 pallette 기준으로 결정하면 좋을 것 같습니다.

결정해야할 부분

  1. body background-color
  2. body color
  3. Main으로 쓸 color 1~2가지
  4. Main과 잘 어울리면서도 12번 발생하는 Sub color 23가지

참고사항

  1. Statistics에서 @hanseul-lee 님께서는 body에서 background-color: #222, color: #fff를 차용하고 있습니다.

  1. Vertical Cluster List에서는 body에서 background-color: #fff, color: #222를 차용하고 있습니다. -> @hanseul-lee 님께서 차용하신 색을 듣고 동일하게 작업을 했는데 합치는 과정에서 그래프가 잘 안보여서 두개를 바꿔 설정하였습니다.

플러스로 Assignees가 10명까지 밖에 안되는 군요 ㅜㅜ

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.