resolve the
conflicts in that work tree.
When done, the user can either finalize the merge with
`git notes merge --commit`, or abort the merge with
`git notes merge --abort`.

Users may select an automated merge strategy from among the following using
either `-s`/`--strategy` option or configuring `notes.mergeStrategy` accordingly:

`ours` automatically resolves conflicting notes in favor of the local
version (i.e. the current notes ref).

`theirs` automatically resolves notes conflicts in favor of the remote
version (i.e. the given notes ref being merged into the current notes
ref).

`union` automatically resolves notes conflicts by concatenating the
local and remote versions.

`cat_sort_uniq` is similar to `union`, but in addition to concatenating
the local and remote versions, this strategy also sorts the resulting
lines, and removes duplicate lines from the result. This is equivalent
to applying the "cat | sort | uniq" shell pipeline to the local and
remote versions. This strategy is useful if the notes follow a line-based
format where one wants to avoid duplicated lines in the merge result.
Note that if either the local or remote version contain duplicate lines
prior to the merge, these will also be removed by this notes merge
strategy.


EXAMPLES
--------

You can use notes to add annotations with information that was not
available at the time a commit was written.

------------
$ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2
$ git show -s 72a144e
[...]
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Notes:
    Tested-by: Johannes Sixt <j6t@kdbg.org>
------------

In principle, a note is a regular Git blob, and any kind of
(non-)format is accepted.  You can binary-safely create notes from
arbitrary files using `git hash-object`:

------------
$ cc *.c
$ blob=$(git hash-object -w a.out)
$ git notes --ref=built add --allow-empty -C "$blob" HEAD
------------

(You cannot simply use `git notes --ref=built add -F a.out HEAD`
because that is not binary-safe.)
Of course, it doesn't make much sense to display non-text-format notes
with `git log`, so if you use such notes, you'll probably need to write
some special-purpose tools to do something useful with them.


[[CONFIGURATION]]
CONFIGURATION
-------------

`core.notesRef`::
	Notes ref to read and manipulate instead of
	`refs/notes/commits`.  Must be an unabbreviated ref name.
	This setting can be overridden through the environment and
	command line.

include::includes/cmd-config-section-rest.adoc[]

include::config/notes.adoc[]


ENVIRONMENT
-----------

`GIT_NOTES_REF`::
	Which ref to manipulate notes from, instead of `refs/notes/commits`.
	This overrides the `core.notesRef` setting.

`GIT_NOTES_DISPLAY_REF`::
	Colon-delimited list of refs or globs indicating which refs,
	in addition to the default from `core.notesRef` or
	`GIT_NOTES_REF`, to read notes from when showing commit
	messages.
	This overrides the `notes.displayRef` setting.
+
A warning will be issued for refs that do not exist, but a glob that
does not match any refs is silently ignored.

`GIT_NOTES_REWRITE_MODE`::
	When copying notes during a rewrite, what to do if the target
	commit already has a note.
	Must be one of `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
	This overrides the `core.rewriteMode` setting.

`GIT_NOTES_REWRITE_REF`::
	When rewriting commits, which notes to copy from the original
	to the rewritten commit.  Must be a colon-delimited list of
	refs or globs.
+
If not set in the environment, the list of notes to copy depends
on the `notes.rewrite.<command>` and `notes.rewriteRef` settings.

GIT
---
Part of the linkgit:git[1] suite