カスタム メタデータをgit commit
. 具体的には、コード レビューからのレビュー ID を記録しますが、それは何でもかまいません。gitk
タグはそれを行うための自然な方法のように思えますが、コミットごとにレビューを行うことを期待しており、大量のタグでごちゃごちゃしたくありません。カスタム メタデータを追加する他のメカニズムはありますか? 特定のタグを非表示にすることはできますか? 何らかのパターンまたは RE に一致するタグを表示しないように指示できればgitk
、うまくいく可能性がありますが、それを行う方法がわかりません。
2 に答える
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: value
1 行に 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 つの Key-Value)。
- 特別なマージ戦略を使用します。
man git-notes
のセクション「Notes マージ戦略」を参照してください。
視認性
OPは尋ねました:
> 特定のタグを非表示にすることはできますか?
デフォルトでは、git log
は 1 つの音符、つまり のみを表示します
.git/refs/notes/commits
。commits
名前空間内の 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
--oneline
man 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 ページには、さまざまなプロジェクトで使用されるさまざまなトレーラー行 (通常はキーと値のペア) がリストされています。
まさにそれがgit ノートの目的です。