Git-Heat-Map - ギットヒートマップ

(NULL)

Created at: 2022-12-16 22:36:36
Language: Python

ギットヒートマップ

グイド・ファン・ロッサムが最も変更したファイルを強調表示したcpythonリポジトリを示すマップ グイド・ファン・ロッサムが最も変更したファイルを強調表示したcpythonリポジトリを示すマップ

基本利用ガイド

  • データベースの生成
    python generate_db.py {path_to_repo_dir}
  • でWebサーバーを実行します(フラスコをインストールする必要があり、pipからインストールできます)
    python flask_app.py
  • 接続先
    127.0.0.1:5000
  • 利用可能なリポジトリが表示されたら、表示するリポジトリを選択します
  • 右側のフォームを使用して強調表示するメールを追加します
  • プレス送信クエリ
  • ディレクトリをクリックしてズームインし、サイドバーの戻るボタンをクリックしてズームアウトします

プロジェクト構造

このプロジェクトは、次の 2 つの部分で構成されています。

  1. Git ログ -> データベース
  2. データベース > ツリーマップ

Git ログ -> データベース

を使用して git 履歴全体をスキャンし、次の 3 つのテーブルを使用してデータベースを作成します。

git log

  • ファイル名を追跡するだけのファイル
  • コミットハッシュ、作成者、コミッターを格納するコミット
  • CommitFileは、特定のコミットによって変更される特定のファイルのインスタンスを格納し、そのコミットによって追加または削除された行数を追跡します。
  • 作成者: 作成者名と電子メールを保存します。
  • CommitAuthor: コミットの共同編集者をサポートするためにコミットと作成者をリンクします。

これらを使用すると、どのファイル/コミットがリポジトリを最も変更したかを追跡でき、それ自体が有用な洞察を提供できます

データベース > ツリーマップ

上記のデータベースでは、SQL クエリを使用して、次の構造の JSON オブジェクトを生成します。

directory:
  "name": <Directory name>
  "val": <Sum of sizes of children>
  "children": [<directory or file>, ...]

file:
  "name": <File name>
  "val": <Total number of line changes for this file over all commits>

次に、これを使用して、ファイルシステムのツリーマップを表すインラインSVGイメージを生成し、各長方形のサイズは上記のとおりです。

val

次に、上記と同様の方法で2番目のJSONオブジェクトを生成しますが、必要なもの(特定の電子メール、日付範囲などのみ)をフィルタリングし、これを使用して、返されたsに基づいてさまざまな強度で長方形を強調表示しますたとえば、特定の作成者によって最も変更されたファイルを強調表示します。

val

パフォーマンス

これらの速度は私のパソコンで達成されました。

データベース生成

レポ コミット数 Git ログ時間 Git ログのサイズ データベース時間 データベースのサイズ 合計時間
リナックス 1,154,884 60分 444メガバイト 462.618秒 733メガバイト 68分
ティッカー 115,874 4.6 分 44.6メガバイト 36.607秒 74.3メガバイト 5.2 分

所要時間は直線的にスケーリングされているようで、約300コミット/秒を通過するか、0.0033秒/コミットが必要です。 データベース サイズも直線的にスケーリングされ、約 2600 コミット/MB、つまり 384 B/コミットが必要です。

データベースのクエリとツリーマップの表示

このテストでは、最も著名な作成者によって各リポジトリをフィルタリングしました。

レポ 作成者フィルター 所要時間
リナックス torvalds@linux-foundation.org 45.4秒
ティッカー guido@python.org 1.9秒

現在、グローバル変数を使用して、パフォーマンスを向上させるために最小のファイルをレンダリングしません。

treemap.js
MIN_AREA

これらのパフォーマンスは期待するほど高速ではありませんが、より一般的なサイズのリポジトリは正常に実行されるはずです。

必要な機能

サブモジュールの追跡

現在、確認できるサブモジュールの変更は、最上位のコミットポインタの変更のみです。将来的には、サブモジュールを再帰的に探索し、それらのファイルをデータベースに追加したいと考えています。

データベース生成の高速化

現在、大規模なリポジトリでは非常に長い時間がかかる可能性のあるgit logを使用して行われます。ファイルに関する必要な情報を取得する他の方法を検討します。

非同期ジャバスクリプト

現在、非同期関数は使用されていません。ファイルの読み込みやsvg描画などが非同期で行われた場合、Webページのパフォーマンスが向上する可能性があると思います。

フィルターの記憶

フィルターは、ページが読み込まれるたびに再入力する必要があります。理想的には、フィルターはCookieを介して、またはフィルターをURLクエリとして保存することによって記憶され、ユーザーがクエリをブックマークできるようになります。

フィルタービルダーサイドバー

現在のインターフェースは非常に必要最低限のものです。ユーザーが著者や日付範囲などを選択して強調表示を制御できるサイドバーが必要です。

著者ごとに選択可能な色

現在、赤はすべての結果に対してハードコードされています。複数の著者を異なる色で強調表示するには、両方の作成者が編集したファイルに色を付ける方法を決定する必要があります。