user/sven/git.git/Documentation/git-notes.txt, branch v1.7.7.4

git-notes.txt: clarify -C vs. copy and -F

2011-08-25T20:16:46Z

The current description of '-C' together with the analogy to 'git commit -C' can lead to the wrong conclusion that '-C' copies notes between objects. Make this clearer by rewording and pointing to 'copy'. The example for attaching binary notes with 'git hash-object' followed by 'git notes add -C' immediately raises the question: "Why not use 'git notes add -F'?". Answer it (the latter is not binary-safe). Signed-off-by: Michael J Gruber Acked-by: Johan Herland Signed-off-by: Junio C Hamano

notes remove: --stdin reads from the standard input

2011-05-19T17:54:16Z

Teach the command to read object names to remove from the standard input, in addition to the object names given from the command line. Signed-off-by: Junio C Hamano

notes remove: --ignore-missing

2011-05-19T17:46:42Z

Depending on the application, it is not necessarily an error for an object to lack a note, especially if the only thing the caller wants to make sure is that notes are cleared for an object. By passing this option from the command line, the "git notes remove" command considers it a success if the object did not have any note to begin with. Signed-off-by: Junio C Hamano

notes remove: allow removing more than one

2011-05-19T17:44:44Z

While "xargs -n1 git notes rm" is certainly a possible way to remove notes from many objects, this would create one notes "commit" per removal, which is not quite suitable for seasonal housekeeping. Allow taking more than one on the command line, and record their removal as a single atomic event if everthing goes well. Even though the old code insisted that "git notes rm" must be given only one object (or zero, in which case it would default to HEAD), this condition was not tested. Add tests to handle the new case where we feed multiple objects, and also make sure if there is a bad input, no change is recorded. Signed-off-by: Junio C Hamano

Make "git notes add" more user-friendly when there are existing notes

2011-03-30T20:13:52Z

Currently, "notes add" (without -f/--force) will abort when the given object already has existing notes. This makes sense for the modes of "git notes add" that would necessarily overwrite the old message (when using the -m/-F/-C/-c options). However, when no options are given (meaning the notes are created from scratch in the editor) it is not very user-friendly to abort on existing notes, and forcing the user to run "git notes edit". Instead, it is better to simply "redirect" to "git notes edit" automatically, i.e. open the existing notes in the editor and let the user edit them. This patch does just that. This changes the behavior of "git notes add" without options when notes already exist for the given object, but I doubt that many users really depend on the previous failure from "git notes add" in this case. Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

Provide 'git notes get-ref' to easily retrieve current notes ref

2010-11-17T21:23:55Z

Script may use 'git notes get-ref' to easily retrieve the current notes ref. Suggested-by: Jonathan Nieder Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

git notes merge: Add another auto-resolving strategy: "cat_sort_uniq"

2010-11-17T21:22:53Z

This new strategy is similar to "concatenate", but in addition to concatenating the two note candidates, this strategy sorts the resulting lines, and removes duplicate lines from the result. This is equivalent to applying the "cat | sort | uniq" shell pipeline to the two note candidates. This strategy is useful if the notes follow a line-based format where one wants to avoid duplicate lines in the merge result. Note that if either of the note candidates contain duplicate lines _prior_ to the merge, these will also be removed by this merge strategy. The patch also contains tests and documentation for the new strategy. Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

git notes merge: Manual conflict resolution, part 2/2

2010-11-17T21:22:49Z

When the notes merge conflicts in .git/NOTES_MERGE_WORKTREE have been resolved, we need to record a new notes commit on the appropriate notes ref with the resolved notes. This patch implements 'git notes merge --commit' which the user should run after resolving conflicts in the notes merge worktree. This command finalizes the notes merge by recombining the partial notes tree from part 1 with the now-resolved conflicts in the notes merge worktree in a merge commit, and updating the appropriate ref to this merge commit. In order to correctly finalize the merge, we need to keep track of three things: - The partial merge result from part 1, containing the auto-merged notes. This is now stored into a ref called .git/NOTES_MERGE_PARTIAL. - The unmerged notes. These are already stored in .git/NOTES_MERGE_WORKTREE, thanks to part 1. - The notes ref to be updated by the finalized merge result. This is now stored in a symref called .git/NOTES_MERGE_REF. In addition to "git notes merge --commit", which uses the above details to create the finalized notes merge commit, this patch also implements "git notes merge --reset", which aborts the ongoing notes merge by simply removing the files/directory described above. FTR, "git notes merge --commit" reuses "git notes merge --reset" to remove the information described above (.git/NOTES_MERGE_*) after the notes merge have been successfully finalized. The patch also contains documentation and testcases for the two new options. This patch has been improved by the following contributions: - Ævar Arnfjörð Bjarmason: Fix nonsense sentence in --commit description - Sverre Rabbelier: Rename --reset to --abort Thanks-to: Ævar Arnfjörð Bjarmason Thanks-to: Sverre Rabbelier Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

git notes merge: Manual conflict resolution, part 1/2

2010-11-17T21:22:49Z

Conflicts (that are to be resolved manually) are written into a special- purpose working tree, located at .git/NOTES_MERGE_WORKTREE. Within this directory, conflicting notes entries are stored (with conflict markers produced by ll_merge()) using the SHA1 of the annotated object. The .git/NOTES_MERGE_WORKTREE directory will only contain the _conflicting_ note entries. The non-conflicting note entries (aka. the partial merge result) are stored in 'local_tree', and the SHA1 of the resulting commit is written to 'result_sha1'. The return value from notes_merge() is -1. The user is told to edit the files within the .git/NOTES_MERGE_WORKTREE directory in order to resolve the conflicts. The patch also contains documentation and testcases for the correct setup of .git/NOTES_MERGE_WORKTREE. The next part will recombine the partial notes merge result with the resolved conflicts in .git/NOTES_MERGE_WORKTREE to produce the complete merge result. This patch has been improved by the following contributions: - Jonathan Nieder: Use trace_printf(...) instead of OUTPUT(o, 5, ...) Thanks-to: Jonathan Nieder Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano

Documentation: Preliminary docs on 'git notes merge'

2010-11-17T21:22:49Z

This patch has been improved by the following contributions: - Stephen Boyd: Use "automatically resolves" instead of "auto-resolves" - Stephen Boyd: Remove unbalanced '(' Thanks-to: Stephen Boyd Signed-off-by: Johan Herland Signed-off-by: Junio C Hamano