git/builtin/worktree.c, branch v2.45.3

Merge branch 'jk/core-comment-string'

2024-04-05T17:49:49Z

core.commentChar used to be limited to a single byte, but has been updated to allow an arbitrary multi-byte sequence. * jk/core-comment-string: config: add core.commentString config: allow multi-byte core.commentChar environment: drop comment_line_char compatibility macro wt-status: drop custom comment-char stringification sequencer: handle multi-byte comment characters when writing todo list find multi-byte comment chars in unterminated buffers find multi-byte comment chars in NUL-terminated strings prefer comment_line_str to comment_line_char for printing strbuf: accept a comment string for strbuf_add_commented_lines() strbuf: accept a comment string for strbuf_commented_addf() strbuf: accept a comment string for strbuf_stripspace() environment: store comment_line_char as a string strbuf: avoid shadowing global comment_line_char name commit: refactor base-case of adjust_comment_line_char() strbuf: avoid static variables in strbuf_add_commented_lines() strbuf: simplify comment-handling in add_lines() helper config: forbid newline as core.commentChar

config: add --comment option to add a comment

2024-03-15T19:25:35Z

Introduce the ability to append comments to modifications made using git-config. Example usage: git config --comment "changed via script" \ --add safe.directory /home/alice/repo.git based on the proposed patch, the output produced is: [safe] directory = /home/alice/repo.git #changed via script Users need to be able to distinguish between config entries made using automation and entries made by a human. Automation can add comments containing a URL pointing to explanations for the change made, avoiding questions from users as to why their config file was changed by a third party. The implementation ensures that a # character is unconditionally prepended to the provided comment string, and that the comment text is appended as a suffix to the changed key-value-pair in the same line of text. Multi-line comments (i.e. comments containing linefeed) are rejected as errors, causing Git to exit without making changes. Comments are aimed at humans who inspect or change their Git config using a pager or editor. Comments are not meant to be read or displayed by git-config at a later time. Signed-off-by: Ralph Seichter Signed-off-by: Junio C Hamano

strbuf: accept a comment string for strbuf_stripspace()

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, let's take a NUL-terminated string pointer for strbuf_stripspace(), rather than a single character. We can continue to support its feature of ignoring comments by accepting a NULL pointer (as opposed to the current behavior of a NUL byte). All of the callers have to be adjusted, but they can all just pass comment_line_str (or NULL). Inside the function we detect comments by comparing the first byte of a line to the comment character. We'll adjust that to use starts_with(), which will match multiple bytes (though for now, of course, we still only allow a single byte, so it's academic). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/comment-style-fixes'

2024-02-06T22:31:21Z

Rewrite //-comments to /* comments */ in files whose comments prevalently use the latter. * jc/comment-style-fixes: reftable/pq_test: comment style fix merge-ort.c: comment style fix builtin/worktree: comment style fixes

builtin/worktree: comment style fixes

2024-01-29T22:08:52Z

Signed-off-by: Junio C Hamano

Merge branch 'ps/worktree-refdb-initialization'

2024-01-26T16:54:46Z

Instead of manually creating refs/ hierarchy on disk upon a creation of a secondary worktree, which is only usable via the files backend, use the refs API to populate it. * ps/worktree-refdb-initialization: builtin/worktree: create refdb via ref backend worktree: expose interface to look up worktree by name builtin/worktree: move setup of commondir file earlier refs/files: skip creation of "refs/{heads,tags}" for worktrees setup: move creation of "refs/" into the files backend refs: prepare `refs_init_db()` for initializing worktree refs

builtin/worktree: create refdb via ref backend

2024-01-08T21:17:30Z

When creating a worktree we create the worktree's ref database manually by first writing a "HEAD" file so that the directory is recognized as a Git repository by other commands, and then running git-update-ref(1) or git-symbolic-ref(1) to write the actual value. But while this is fine for the files backend, this logic simply assumes too much about how the ref backend works and will leave behind an invalid ref database once any other ref backend lands. Refactor the code to instead use `refs_init_db()` to initialize the ref database so that git-worktree(1) itself does not need to know about how to initialize it. This will allow future ref backends to customize how the per-worktree ref database is set up. Furthermore, as we now already have a worktree ref store around, we can also avoid spawning external commands to write the HEAD reference and instead use the refs API to do so. Note that we do not have an equivalent to passing the `--quiet` flag to git-symbolic-ref(1) as we did before. This flag does not have an effect anyway though, as git-symbolic-ref(1) only honors it when reading a symref, but never when writing one. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

builtin/worktree: move setup of commondir file earlier

2024-01-08T21:17:30Z

Shuffle around how we create supporting worktree files so that we first ensure that the worktree has all link files ("gitdir", "commondir") before we try to initialize the ref database by writing "HEAD". This will be required by a subsequent commit where we start to initialize the ref database via `refs_init_db()`, which will require an initialized `struct worktree *`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'jc/orphan-unborn'

2024-01-02T21:51:30Z

Doc updates to clarify what an "unborn branch" means. * jc/orphan-unborn: orphan/unborn: fix use of 'orphan' in end-user facing messages orphan/unborn: add to the glossary and use them consistently

worktree: simplify incompatibility message for --orphan and commit-ish

2023-12-08T22:41:03Z

Use a single translatable string to report that the worktree add option --orphan is incompatible with a commit-ish instead of having the commit-ish in a separate translatable string. This reduces the number of strings to translate and gives translators the full context. A similar message is used in builtin/describe.c, but with the plural of commit-ish, and here we need the singular form. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano