GIT-примечания
С помощью git notes вы можете добавить «примечание» к коммиту. Вы также можете добавить их
для других объектов Git, но давайте просто сосредоточимся на коммитах, так как это то, что
вопрос о.
Заметка является объектом Git и в принципе может быть «что угодно» (произвольно
данные). Но мы сосредоточимся на чем-то простом и текстовом для наших целей.
Пример: идентификатор отзыва
В вопросе упоминаются идентификаторы обзора, поэтому давайте придумаем способ представить
такая вещь Я не знаю, как на самом деле выглядят идентификаторы, но
надеюсь, было бы целесообразно следующее:
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, чтобы легко добавить эти дополнительные данные в
нота. Вы также можете использовать git notes edit для редактирования файла
непосредственно.
Конечно, поскольку заметка Git - это всего лишь один изменяемый файл, вы можете запустить
в конфликты слияния. Чтобы сделать это менее вероятным, вы можете:
- Придерживайтесь простых данных, как указано выше (одно значение ключа на строку).
- Использовать специальные стратегии слияния; см
man git-notes, раздел «Примечания
стратегии слияния ».
Видимость
ОП спросил:
> Могу ли я сделать определенные теги невидимыми?
По умолчанию git log показывает только одну заметку, а именно
.git/refs/notes/commits. commits - это только одна заметка в пространстве имен.
Возможно, вы хотите, чтобы эмитент находился в собственном пространстве имен:
git notes --ref=issues add -m "Fixes: #32"
Так как это хранится в .git/refs/notes/issues, а не в
.git/refs/notes/commits, «Исправления: # 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-заметки с другой стороны изменчивы, поэтому вы всегда можете
пересмотреть их. И каждая модификация заметки, конечно, версия
контролируется. В нашем случае для .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/*
(Источник: https://git -scm.com / blog / 2010/08/25 / notes.html )
Перенос заметок при перезаписи
Git имеет неудобное значение по умолчанию, что заметки не переносятся при фиксации
переписан Так что если вы, например, перебазируете серию коммитов, заметки будут
не переносить на новые коммиты.
Переменная notes.rewrite.<command> по умолчанию установлена на true, так что можно
Предположим, что примечания переносятся . Но проблема в том, что переменная
notes.rewriteRef, который определяет , какие ноты будут перенесены, не имеет
глухой vaule. Чтобы установить это значение, чтобы соответствоватьВсе замечания, выполните следующее:
git config --global notes.rewriteRef "refs/notes/*"
Теперь все заметки будут перенесены при выполнении операций перезаписи, таких как git
rebase.
Перенос заметок через почтовые патчи
Если вы используете git format-patch для форматирования ваших изменений, которые будут отправлены как электронные письма,
и у вас есть некоторые метаданные, хранящиеся в виде заметок Git, вы можете передать --notes
опция git format-patch для добавления примечаний к черновику электронного письма.
† 1: «Это значение по умолчанию для git log […], когда нет --pretty,
Параметр --format или --oneline задан в командной строке. ”- man git-log, версия git 2.10.2
† 2: одна практика / соглашение для метаданных в сообщениях коммита, которая используется в таких проектах, как, например, Git и ядро Linux - это добавление пар ключ-значение в «трейлер» сообщения фиксации, то есть внизу. См. Например этот коммит Линуса Торвальдса:
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- Это вики-страница ядра , в которой перечислены различные строки трейлера (обычно пары ключ-значение), которые используются в различных проектах.