git/Documentation/git-notes.txt, branch v2.48.2

notes: teach the -e option to edit messages in editor

2024-10-21T19:52:48Z

Notes can be added to a commit using: - "-m" to provide a message on the command line. - -C to copy a note from a blob object. - -F to read the note from a file. When these options are used, Git does not open an editor, it simply takes the content provided via these options and attaches it to the commit as a note. Improve flexibility to fine-tune the note before finalizing it by allowing the messages to be prefilled in the editor and edited after the messages have been provided through -[mF]. Signed-off-by: Abraham Samuel Adekunle Signed-off-by: Taylor Blau

doc: enforce dashes in placeholders

2023-12-26T19:06:55Z

The CodingGuidelines documents stipulates that multi-word placeholders are to be separated by dashes, not underscores nor spaces. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

notes doc: tidy up `--no-stripspace` paragraph

2023-08-16T18:37:25Z

Where we document the `--no-stripspace` option, remove a superfluous "For" to fix the grammar. Mark option names and command names using `backticks` to set them in monospace. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

notes doc: split up run-on sentences

2023-08-16T18:36:36Z

When commit c4e2aa7d45 (notes.c: introduce "--[no-]stripspace" option, 2023-05-27) mentioned the new `--no-stripspace` in the documentation for `-m` and `-F`, it created run-on sentences. It also used slightly different language in the two sections for no apparent reason. Split the sentences in two to improve readability, and while touching the two sites, make them more similar. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

notes: introduce "--no-separator" option

2023-06-21T15:51:01Z

Sometimes, the user may want to add or append multiple notes without any separator to be added between them. Disscussion: https://public-inbox.org/git/3f86a553-246a-4626-b1bd-bacd8148318a@app.fastmail.com/ Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

notes.c: introduce "--[no-]stripspace" option

2023-06-21T15:51:01Z

This commit introduces a new option "--[no-]stripspace" to git notes append, git notes edit, and git notes add. This option allows users to control whether the note message need to stripped out. For the consideration of backward compatibility, let's look at the behavior about "stripspace" in "git notes" command: 1. "Edit Message" case: using the default editor to edit the note message. In "edit" case, the edited message will always be stripped out, the implementation which can be found in the "prepare_note_data()". In addition, the "-c" option supports to reuse an existing blob as a note message, then open the editor to make a further edition on it, the edited message will be stripped. This commit doesn't change the default behavior of "edit" case by using an enum "notes_stripspace", only when "--no-stripspace" option is specified, the note message will not be stripped out. If you do not specify the option or you specify "--stripspace", clearly, the note message will be stripped out. 2. "Assign Message" case: using the "-m"/"-F"/"-C" option to specify the note message. In "assign" case, when specify message by "-m" or "-F", the message will be stripped out by default, but when specify message by "-C", the message will be copied verbatim, in other word, the message will not be stripped out. One more thing need to note is "the order of the options matter", that is, if you specify "-C" before "-m" or "-F", the reused message by "-C" will be stripped out together, because everytime concat "-m" or "-F" message, the concated message will be stripped together. Oppositely, if you specify "-m" or "-F" before "-C", the reused message by "-C" will not be stripped out. This commit doesn't change the default behavior of "assign" case by extending the "stripspace" field in "struct note_msg", so we can distinguish the different behavior of "-m"/"-F" and "-C" options when we need to parse and concat the message. Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

notes.c: introduce '--separator=' option

2023-06-21T15:51:00Z

When adding new notes or appending to an existing notes, we will insert a blank line between the paragraphs, like: $ git notes add -m foo -m bar $ git notes show HEAD foo bar The default behavour sometimes is not enough, the user may want to use a custom delimiter between paragraphs, like when specifying '-m', '-F', '-C', '-c' options. So this commit introduce a new '--separator' option for 'git notes add' and 'git notes append', for example when executing: $ git notes add -m foo -m bar --separator="-" $ git notes show HEAD foo - bar a newline is added to the value given to --separator if it does not end with one already. So when executing: $ git notes add -m foo -m bar --separator="-" and $ export LF=" " $ git notes add -m foo -m bar --separator="-$LF" Both the two exections produce the same result. The reason we use a "strbuf" array to concat but not "string_list", is that the binary file content may contain '\0' in the middle, this will cause the corrupt result if using a string to save. Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

notes docs: de-duplicate and combine configuration sections

2022-09-07T16:46:06Z

Combine the various "notes" configuration sections spread across Documentation/config/notes.txt and Documentation/git-notes.txt to live in the former, and to be included in the latter. We'll now forward link from "git notes" to the "CONFIGURATION" section below, rather than to "git-config(1)" when discussing configuration variables that are (also) discussed in that section. Signed-off-by: Ævar Arnfjörð Bjarmason Reviewed-by: Matheus Tavares Signed-off-by: Junio C Hamano

docs: improve the example that illustrates git-notes path names

2020-08-03T19:40:09Z

Make it clear that the filename has only the rest of the object ID, not the entirety of it. Signed-off-by: Noam Yorav-Raphael Acked-by: Taylor Blau Signed-off-by: Junio C Hamano

notes: fix minimum number of parameters to "copy" subcommand

2019-10-18T00:43:10Z

The builtin/notes.c::copy() function is prepared to handle either one or two arguments given from the command line; when one argument is given, to-obj defaults to HEAD. bbb1b8a3 ("notes: check number of parameters to "git notes copy"", 2010-06-28) tried to make sure "git notes copy" (with *no* other argument) does not dereference NULL by checking the number of parameters, but it incorrectly insisted that we need two arguments, instead of either one or two. This disabled the defaulting to-obj to HEAD. Correct it. Signed-off-by: Doan Tran Cong Danh Signed-off-by: Junio C Hamano