git/builtin/notes.c, branch v2.40.2

notes: avoid empty line in template

2022-11-16T19:57:32Z

When `git notes` prepares the template it adds an empty newline between the comment header and the content: > > # > # Write/edit the notes for the following object: > > # commit 0f3c55d4c2b7864bffb2d92278eff08d0b2e083f > # etc This is wrong structurally because that newline is part of the comment, too, and thus should be commented. Also, it throws off some positioning strategies of editors and plugins, and it differs from how we do commit templates. Change this to follow the standard set by `git commit`: > > # > # Write/edit the notes for the following object: > # > # commit 0f3c55d4c2b7864bffb2d92278eff08d0b2e083f > Tests pass unchanged after this code change. Signed-off-by: Michael J Gruber Signed-off-by: Taylor Blau

notes, remote: show unknown subcommands between `'

2022-09-07T19:06:12Z

Update the "unknown subcommand" error message in 'git notes' and 'git remote' to wrap the offending argument between `', to make it consistent with the "unknown switch/option/subcommand" error messages in parse-options. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

notes: simplify default operation mode arguments check

2022-09-07T19:06:12Z

'git notes' has a default operation mode, but when invoked without a subcommand it doesn't accept any arguments (although the 'list' subcommand implementing the default operation mode does accept arguments). The condition checking this ended up a bit awkward, so let's make it clearer. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

builtin/notes.c: let parse-options parse subcommands

2022-08-19T18:13:15Z

'git notes' parses its subcommands with a long list of if-else if statements. parse-options has just learned to parse subcommands, so let's use that facility instead, with the benefits of shorter code, handling unknown subcommands, and listing subcommands for Bash completion. Make sure that the default operation mode doesn't accept any arguments. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

Merge branch 'ab/object-file-api-updates'

2022-03-17T00:53:08Z

Object-file API shuffling. * ab/object-file-api-updates: object-file API: pass an enum to read_object_with_reference() object-file.c: add a literal version of write_object_file_prepare() object-file API: have hash_object_file() take "enum object_type" object API: rename hash_object_file_literally() to write_*() object-file API: split up and simplify check_object_signature() object API users + docs: check <0, not !0 with check_object_signature() object API docs: move check_object_signature() docs to cache.h object API: correct "buf" v.s. "map" mismatch in *.c and *.h object-file API: have write_object_file() take "enum object_type" object-file API: add a format_object_header() function object-file API: return "void", not "int" from hash_object_file() object-file.c: split up declaration of unrelated variables

object-file API: have write_object_file() take "enum object_type"

2022-02-26T01:16:31Z

Change the write_object_file() function to take an "enum object_type" instead of a "const char *type". Its callers either passed {commit,tree,blob,tag}_type and can pass the corresponding OBJ_* type instead, or were hardcoding strings like "blob". This avoids the back & forth fragility where the callers of write_object_file() would have the enum type, and convert it themselves via type_name(). We do have to now do that conversion ourselves before calling write_object_file_prepare(), but those codepaths will be similarly adjusted in subsequent commits. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

i18n: remove from i18n strings that do not hold translatable parts

2022-02-04T21:58:28Z

Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Merge branch 'ab/usage-die-message'

2022-01-10T19:52:53Z

Code clean-up to hide vreportf() from public API. * ab/usage-die-message: config API: use get_error_routine(), not vreportf() usage.c + gc: add and use a die_message_errno() gc: return from cmd_gc(), don't call exit() usage.c API users: use die_message() for error() + exit 128 usage.c API users: use die_message() for "fatal :" + exit 128 usage.c: add a die_message() routine

Merge branch 'ak/protect-any-current-branch'

2021-12-21T23:03:16Z

"git fetch" without the "--update-head-ok" option ought to protect a checked out branch from getting updated, to prevent the working tree that checks it out to go out of sync. The code was written before the use of "git worktree" got widespread, and only checked the branch that was checked out in the current worktree, which has been updated. (originally called ak/fetch-not-overwrite-any-current-branch) * ak/protect-any-current-branch: branch: protect branches checked out in all worktrees receive-pack: protect current branch for bare repository worktree receive-pack: clean dead code from update_worktree() fetch: protect branches checked out in all worktrees worktree: simplify find_shared_symref() memory ownership model branch: lowercase error messages receive-pack: lowercase error messages fetch: lowercase error messages

usage.c API users: use die_message() for error() + exit 128

2021-12-07T21:25:15Z

Continue the migration of code that printed a message and exited with 128. In this case the caller used "error()", so we'll be changing the output from "error: " to "fatal: ". This change is intentional and desired. This code is dying, so it should emit "fatal", the only reason it didn't do so was because before the existence of "die_message()" it would have needed to craft its own "fatal: " message. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano