git/builtin/worktree.c, branch gitk-resize-error

i18n: factorize "--foo requires --bar" and the like

2022-01-05T21:31:00Z

They are all replaced by "the option '%s' requires '%s'", which is a new string but replaces 17 previous unique strings. Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

i18n: refactor "%s, %s and %s are mutually exclusive"

2022-01-05T21:29:23Z

Use placeholders for constant tokens. The strings are turned into "cannot be used together" Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

i18n: refactor "foo and bar are mutually exclusive"

2022-01-05T21:29:23Z

Use static strings for constant parts of the sentences. They are all turned into "cannot be used together". Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'es/worktree-chatty-to-stderr'

2021-12-15T17:39:49Z

"git worktree add" showed "Preparing worktree" message to the standard output stream, but when it failed, the message from die() went to the standard error stream. Depending on the order the stdio streams are flushed at the program end, this resulted in confusing output. It has been corrected by sending all the chatty messages to the standard error stream. * es/worktree-chatty-to-stderr: git-worktree.txt: add missing `-v` to synopsis for `worktree list` worktree: send "chatty" messages to stderr

worktree: send "chatty" messages to stderr

2021-12-05T07:27:11Z

The order in which the stdout and stderr streams are flushed is not guaranteed to be the same across platforms or `libc` implementations. This lack of determinism can lead to anomalous and potentially confusing output if normal (stdout) output is flushed after error (stderr) output. For instance, the following output which clearly indicates a failure due to a fatal error: % git worktree add ../foo bar Preparing worktree (checking out 'bar') fatal: 'bar' is already checked out at '.../wherever' has been reported[1] on Microsoft Windows to appear as: % git worktree add ../foo bar fatal: 'bar' is already checked out at '.../wherever' Preparing worktree (checking out 'bar') which may confuse the reader into thinking that the command somehow recovered and ran to completion despite the error. This problem crops up because the "chatty" status message "Preparing worktree" is sent to stdout, whereas the "fatal" error message is sent to stderr. One way to fix this would be to flush stdout manually before git-worktree reports any errors to stderr. However, common practice in Git is for "chatty" messages to be sent to stderr. Therefore, a more appropriate fix is to adjust git-worktree to conform to that practice by sending its "chatty" messages to stderr rather than stdout as is currently the case. There may be concern that relocating messages from stdout to stderr could break existing tooling, however, these messages are already internationalized, thus are unstable. And, indeed, the "Preparing worktree" message has already been the subject of somewhat significant changes in 2c27002a0a (worktree: improve message when creating a new worktree, 2018-04-24). Moreover, there is existing precedent, such as 68b939b2f0 (clone: send diagnostic messages to stderr, 2013-09-18) which likewise relocated "chatty" messages from stdout to stderr for git-clone. [1]: https://lore.kernel.org/git/CA+34VNLj6VB1kCkA=MfM7TZR+6HgqNi5-UaziAoCXacSVkch4A@mail.gmail.com/T/ Reported-by: Baruch Burstein Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

run-command API: remove "env" member, always use "env_array"

2021-11-26T06:15:08Z

Remove the "env" member from "struct child_process" in favor of always using the "env_array". As with the preceding removal of "argv" in favor of "args" this gets rid of current and future oddities around memory management at the API boundary (see the amended API docs). For some of the conversions we can replace patterns like: child.env = env->v; With: strvec_pushv(&child.env_array, env->v); But for others we need to guard the strvec_pushv() with a NULL check, since we're not passing in the "v" member of a "struct strvec", e.g. in the case of tmp_objdir_env()'s return value. Ideally we'd rename the "env_array" member to simply "env" as a follow-up, since it and "args" are now inconsistent in not having an "_array" suffix, and seemingly without any good reason, unless we look at the history of how they came to be. But as we've currently got 122 in-tree hits for a "git grep env_array" let's leave that for now (and possibly forever). Doing that rename would be too disruptive. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

worktree: stop being overly intimate with run_command() internals

2021-11-26T06:15:07Z

add_worktree() reuses a `child_process` for three run_command() invocations, but to do so, it has overly-intimate knowledge of run-command.c internals. In particular, it knows that it must reset child_process::argv to NULL for each subsequent invocation[*] in order for start_command() to latch the newly-populated child_process::args for each invocation, even though this behavior is not a part of the documented API. Beyond having overly-intimate knowledge of run-command.c internals, the reuse of one `child_process` for three run_command() invocations smells like an unnecessary micro-optimization. Therefore, stop sharing one `child_process` and instead use a new one for each run_command() call. [*] If child_process::argv is not reset to NULL, then subsequent run_command() invocations will instead incorrectly access a dangling pointer to freed memory which had been allocated by child_process::args on the previous run. This is due to the following code in start_command(): if (!cmd->argv) cmd->argv = cmd->args.v; Signed-off-by: Eric Sunshine Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

hook.[ch]: move find_hook() from run-command.c to hook.c

2021-09-27T16:44:54Z

Move the find_hook() function from run-command.c to a new hook.c library. This change establishes a stub library that's pretty pointless right now, but will see much wider use with Emily Shaffer's upcoming "configuration-based hooks" series. Eventually all the hook related code will live in hook.[ch]. Let's start that process by moving the simple find_hook() function over as-is. Signed-off-by: Emily Shaffer Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

worktree: teach `add` to accept --reason with --lock

2021-07-15T20:30:59Z

The default reason stored in the lock file, "added with --lock", is unlikely to be what the user would have given in a separate `git worktree lock` command. Allowing `--reason` to be specified along with `--lock` when adding a working tree gives the user control over the reason for locking without needing a second command. Signed-off-by: Stephen Manz Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: mark lock strings with `_()` for translation

2021-07-14T16:29:59Z

- default lock string, "added with --lock" - temporary lock string, "initializing" Signed-off-by: Stephen Manz Reviewed-by: Eric Sunshine Signed-off-by: Junio C Hamano