Setup and Config
Getting and Creating Projects
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
- 2.6.1 no changes
- 2.6.0 09/28/15
- 2.5.2 → 2.5.4 no changes
- 2.5.1 08/28/15
- 2.5.0 07/27/15
- 2.4.10 no changes
- 2.4.9 09/04/15
- 2.4.1 → 2.4.8 no changes
- 2.4.0 04/30/15
- 2.3.9 09/04/15
- 2.3.1 → 2.3.8 no changes
- 2.3.0 02/05/15
- 2.0.1 → 2.2.2 no changes
- 2.0.0 05/28/14
- 1.9.1 → 1.9.5 no changes
- 1.9.0 02/14/14
- 18.104.22.168 → 22.214.171.124 no changes
- 1.8.1 12/31/12
- 126.96.36.199 → 188.8.131.52 no changes
- 184.108.40.206 05/25/12
git-notes(1) Manual Page
git-notes - Add/inspect object notes
git notes [list [<object>]] git notes add [-f] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] git notes copy [-f] ( --stdin | <from-object> <to-object> ) git notes append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] git notes edit [<object>] git notes show [<object>] git notes remove [<object>] git notes prune
This command allows you to add/remove notes to/from objects, without changing the objects themselves.
A typical use of notes is to extend a commit message without having to change the commit itself. Such commit notes can be shown by git log along with the original commit message. To discern these notes from the message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for the default setting).
This command always manipulates the notes specified in "core.notesRef" (see git-config(1)), which can be overridden by GIT_NOTES_REF. To change which notes are shown by git-log, see the "notes.displayRef" configuration.
See the description of "notes.rewrite.<command>" in git-config(1) for a way of carrying your notes across commands that rewrite commits.
List the notes object for a given object. If no object is given, show a list of all note objects and the objects they annotate (in the format "<note object> <annotated object>"). This is the default subcommand if no subcommand is given.
Add notes for a given object (defaults to HEAD). Abort if the object already has notes (use -f to overwrite an existing note).
Copy the notes for the first object onto the second object. Abort if the second object already has notes, or if the first object has none (use -f to overwrite existing notes to the second object). This subcommand is equivalent to: git notes add [-f] -C $(git notes list <from-object>) <to-object>
In --stdin mode, take lines in the format
<from-object> SP <to-object> [ SP <rest> ] LF
on standard input, and copy the notes from each <from-object> to its corresponding <to-object>. (The optional <rest> is ignored so that the command can read the input given to the post-rewrite hook.)
Append to the notes of an existing object (defaults to HEAD). Creates a new notes object if needed.
Edit the notes for a given object (defaults to HEAD).
Show the notes for a given object (defaults to HEAD).
Remove the notes for a given object (defaults to HEAD). This is equivalent to specifying an empty note message to the edit subcommand.
Remove all notes for non-existing/unreachable objects.
When adding notes to an object that already has notes, overwrite the existing notes (instead of aborting).
- -m <msg>
Use the given note message (instead of prompting). If multiple -m options are given, their values are concatenated as separate paragraphs.
- -F <file>
Take the note message from the given file. Use - to read the note message from the standard input.
- -C <object>
Reuse the note message from the given note object.
- -c <object>
Like -C, but with -c the editor is invoked, so that the user can further edit the note message.
- --ref <ref>
Manipulate the notes tree in <ref>. This overrides both GIT_NOTES_REF and the "core.notesRef" configuration. The ref is taken to be in refs/notes/ if it is not qualified.
Every notes change creates a new commit at the specified notes ref. You can therefore inspect the history of the notes by invoking, e.g., git log -p notes/commits.
Currently the commit message only records which operation triggered the update, and the commit authorship is determined according to the usual rules (see git-commit(1)). These details may change in the future.
Written by Johannes Schindelin <email@example.com> and Johan Herland <firstname.lastname@example.org>
Documentation by Johannes Schindelin and Johan Herland
Part of the git(7) suite