51

カスタム メタデータをgit commit. 具体的には、コード レビューからのレビュー ID を記録しますが、それは何でもかまいません。gitkタグはそれを行うための自然な方法のように思えますが、コミットごとにレビューを行うことを期待しており、大量のタグでごちゃごちゃしたくありません。カスタム メタデータを追加する他のメカニズムはありますか? 特定のタグを非表示にすることはできますか? 何らかのパターンまたは RE に一致するタグを表示しないように指示できればgitk、うまくいく可能性がありますが、それを行う方法がわかりません。

4

2 に答える 2

54

Git ノート

コミットにgit notes「メモ」を追加できます。それらを他のGitオブジェクトに追加することもできますが、それが問題であるため、コミットに焦点を当てましょう。

メモは Git オブジェクトであり、原則として「何でも」(任意のデータ) にすることができます。しかし、ここでは目的のために単純でテキスト的なものに焦点を当てます。

例: レビュー ID

質問はレビューIDに言及しているので、そのようなことを表す方法を考えてみましょう。レビューIDが実際にどのように見えるかはわかりませんが、うまくいけば次のようになります。

Review-id: 42

したがって、これは実質的にキーと値のペアです。上記の文字列を現在のコミットに追加しましょう。

git notes add -m "Review-id: 42"

実行するgit logと、メモはインラインで表示されます:(†1)

Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

もう一つの例

もちろん、このメモにさらに「サブメモ」を追加することもできます ( key: value1 行に 1 つの値という単純な構文を使用します)。たとえば、3 か月後にコミット メッセージに問題があることがわかった場合は、メモに修正を追加するだけです。

git notes append -m "Errata: It was actually feature y."

git log:

Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

    Errata: It was actually feature y.

git notes appendこの追加データをメモに簡単に追加するために使用します。git notes editファイルを直接編集するために使用することもできます。

もちろん、Git ノートは単一の変更可能なファイルであるため、マージの競合が発生する可能性があります。その可能性を低くするために、次のことができます。

  1. 上記のような単純なデータに固執します (1 行に 1 つの Key-Value)。
  2. 特別なマージ戦略を使用します。man git-notesのセクション「Notes マージ戦略」を参照してください。

視認性

OPは尋ねました:

> 特定のタグを非表示にすることはできますか?

デフォルトでは、git logは 1 つの音符、つまり のみを表示します .git/refs/notes/commitscommits名前空間内の 1 つのメモにすぎません。課題を独自の名前空間に入れたいと思うかもしれません:

git notes --ref=issues add -m "Fixes: #32"

.git/refs/notes/issuesこれは ではなく に 保存されて.git/refs/notes/commitsいるため、 を実行しても「Fixes: #32」は表示されません git log。したがって、デフォルトでそのようなメモを効果的に非表示にしました。

表示したい場合は、に渡し--notes=issuesますgit log

$ git log --notes=issues
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

しかし、今.git/refs/notes/commitsは隠されています。それも簡単に含めることができます:

$ git log --notes=issues --notes=commits
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

Notes:
    Review-id: 42

    Errata: It was actually feature y.

デフォルトで表示されるメモを設定する変数があります。を参照してください man git-config

コミット メッセージと比較したメリット

もちろん、メタデータはコミット メッセージに直接記録することができます (†2)。しかし、コミット メッセージは不変であるため、それらを変更することは、まったく新しいコミットを作成することを意味し、それに伴うすべてのさざなみの結果を伴います。一方、Git-notes は可変であるため、いつでも変更できます。もちろん、メモの各変更はバージョン管理されています。この場合、次の場合.git/refs/notes/commits:

$ git log refs/notes/commits
Author: Victor Version Control <vvc@vcs.org>
commit 9f0697c6bbbc6a97ecce9834d4c9afa0d668bcad
Date:   Tue Nov 8 21:13:52 2016 +0100

    Notes added by 'git notes append'

commit b60997e49444732ed2defc8a6ca88e9e21001a1d
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:38 2016 +0100

    Notes added by 'git notes add'

メモの共有

メモはデフォルトでは共有されません。明示的に行う必要があります。また、他の参考文献と比較して、メモの共有はあまりユーザーフレンドリーではありません。refspec構文を使用する必要があります。

git push refs/notes/*

上記は、すべてのメモをリモートにプッシュします。

メモの取得はもう少し複雑なようです。refspec の両側を指定すると、それを行うことができます。

git fetch origin refs/notes/*:refs/notes/*

だから、それは間違いなく便利ではありません。Git-notes を定期的に使用する場合は、常にメモを取得するように gitconfig を設定することをお勧めします。

[remote "origin"]
    …
    fetch = +refs/notes/*:refs/notes/*

書き直しのメモを引き継ぐ

Git には、コミットが書き換えられたときにメモが引き継がれないという不便なデフォルトがあります。したがって、たとえば一連のコミットをリベースすると、メモは新しいコミットに引き継がれません。

変数notes.rewrite.<command>はデフォルトで に設定されてtrueいるため、メモ引き継がれると思われるかもしれません。しかし問題は、 どの音符が引き継がれるnotes.rewriteRefかを決定する変数 にデフォルトの値がないことです。この値をすべてのノートに一致するように設定するには、次のコマンドを実行します。

git config --global notes.rewriteRef "refs/notes/*"

のような書き換え操作を行うと、すべてのノートが引き継がれるようになりましたgit rebase

メールパッチでメモを引き継ぐ

git format-patch変更をメールとして送信するためにを使用していて、一部のメタデータが Git メモとして保存されている場合は、メモをメールの下書きに追加するために に--notes オプションを渡すことができます。git format-patch


† 1: 「これは、コマンド ラインで、 、またはオプションが指定されてgit logいない場合の […]のデフォルトです。」― 、gitバージョン2.10.2--pretty--format--onelineman git-log

† 2: Git や Linux カーネルなどのプロジェクトで使用されるメタデータ イン コミット メッセージのプラクティス/慣習の 1 つは、コミット メッセージの「トレーラー」、つまり下部にキーと値のペアを追加することです。たとえば、Linus Torvalds によるこのコミットを参照してください。

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
 Acked-by: Hugh Dickins <hughd@google.com>
 Reviewed-by: Michal Hocko <mhocko@suse.com>
 Cc: Andy Lutomirski <luto@kernel.org>
 Cc: Kees Cook <keescook@chromium.org>
 Cc: Oleg Nesterov <oleg@redhat.com>
 Cc: Willy Tarreau <w@1wt.eu>
 Cc: Nick Piggin <npiggin@gmail.com>
 Cc: Greg Thelen <gthelen@google.com>
 Cc: stable@vger.kernel.org
 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

見る:

  • man git-interpret-trailers
  • このカーネル Wiki ページには、さまざまなプロジェクトで使用されるさまざまなトレーラー行 (通常はキーと値のペア) がリストされています。
于 2016-11-08T21:31:46.580 に答える
43

まさにそれがgit ノートの目的です。

于 2010-04-21T13:52:02.463 に答える