我可以向git提交添加元数据吗？或者我可以在gitk中隐藏一些标签

时间：2010-04-21 13:24:14

标签： git tags metadata gitk

我想将自定义元数据与git commit相关联。专门用于记录代码审查中的审阅ID，但它可以是任何内容。标签似乎是一种自然的方式，但我希望每次提交都有一个评论，我不想让gitk混乱大量的标签。是否有其他机制来添加自定义元数据？我可以让某些标签隐身吗？如果我可以告诉gitk不显示与某些模式或RE匹配的标签，那可能会有效，但我没有办法做到这一点。

2 个答案:

答案 0 :(得分：34)

这正是git notes的用途。

答案 1 :(得分：25)

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语法，每行一个值）。例如，如果你 三个月后发现提交消息有所改变 错了，只需将更正附加到注释中：

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来轻松地将这些额外数据添加到。{1}} 注意。您还可以使用git notes edit来编辑文件 直接

当然，由于Git注释只是一个可变文件，因此您可以运行 合并冲突。为了减少这种可能性，您可以：

  1. 坚持上述简单数据（每行一个键值）。
  2. 使用特殊合并策略;请参阅man git-notes，“注释 合并策略“。

    3. 可见性

    OP问道：

    ＆GT;我可以让某些标签隐身吗？

    默认情况下，git log仅显示一个音符，即 .git/refs/notes/commits。 commits只是命名空间中的一个注释。 也许你希望问题在他们自己的命名空间中：

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

    因为它存储在.git/refs/notes/issues而不是存储在.git/refs/notes/commits中 当你跑步时，git log，“修正：＃32”不会出现 --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

    有些变量可以配置默认显示的注释;看到 .git/refs/notes/commits。

    与提交消息相比的好处

    元数据当然可以直接记录在提交消息中。（†2）但是 提交消息是不可变的，所以要改变它们真的意味着要做一个 全新的提交，带来所有涟漪的后果。 另一方面，Git-notes是可变的，所以你总能做到 修改它们。注释的每个修改当然是版本 受控。在我们的例子中，$ 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' ：

    git push refs/notes/*

    分享笔记

    默认情况下不会分享您的笔记;你必须明确地这样做。和 与其他参考文献相比，共享笔记不是非常人性化。我们有 使用 refspec 语法：

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

    以上内容会将您的所有笔记都推送到遥控器上。

    似乎更多地涉及提取笔记;你可以做到 你指定refspec的两面：

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

    所以这绝对不方便。如果你打算使用Git-notes 经常，您可能希望将gitconfig设置为始终获取 注意到：

    notes.rewrite.<command>

    （资料来源：https://git-scm.com/blog/2010/08/25/notes.html）

    继续重写笔记

    Git有一个不方便的默认值，即提交时不会记录笔记 被重写。因此，如果您举例说明一系列提交，那么注释就会 不要转入新的提交。

    变量true默认情况下设置为notes.rewriteRef，因此有人可能会这样做 假设笔记 被遗留下来。但问题在于变量 确定哪些笔记将被转移的git config --global notes.rewriteRef "refs/notes/*" 没有 聋人的vaule。要将此值设置为与所有音符匹配，请执行以下操作：

    git
rebase

    现在，在执行git format-patch等重写操作时，所有注释都将被转移。

    通过电子邮件补丁进行记录

    如果您使用--notes格式化更改以作为电子邮件发送， 并且你有一些元数据存储为Git笔记，你可以通过git format-patch git log的选项，以便将备注附加到电子邮件草稿中。

    †1：“当没有--pretty时，这是--format [...]的默认设置， 命令行中提供了--oneline或man git-log选项。“ - 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> ，git version 2.10.2

    †2：在项目中使用的元数据提交消息的一种惯例/惯例，例如Git和Linux内核是在提交消息的“预告片”中添加键值对，即在底部。例如，参见Linus Torvalds的this commit：

    man git-interpret-trailers

    请参阅：

    • {{1}}
    • This Kernel Wiki page列出了各种项目中使用的各种预告片行（通常是键值对）。
相关问题
最新问题