Subject: Re: [PATCH] submodule--helper: fix incorrect newlines in an error message

From: Atharva Raykar <[email-masked]>
Date: Fri, 06 Aug 2021 11:59:41 +0530

Kaartic Sivaraam <[email-masked]> writes:

> A refactoring[1] done as part of the recent conversion of
> 'git submodule add' to builtin, changed the error message
> shown when a Git directory already exists locally for a submodule
> name. Before the refactoring, the error used to appear like so:
>
> [...]
>
> As one could observe the remote information is printed along with the
> first line rather than on its own line. Also, there's an additional
> newline following output.
>
> Make the error message consistent with the error message that used to be
> printed before the refactoring.

Thanks for catching this and sending a patch!

> [1]: https://lore.kernel.org/git/[email-masked]/#t
>
> Signed-off-by: Kaartic Sivaraam <[email-masked]>
> ---
>
> Even with this patch, the error message is still not fully consistent with the one that
> used to be printed before the refactoring. Here's the diff:
>
> 3c3
> < If you want to reuse this local git directory instead of cloning again from
> ---
>> fatal: If you want to reuse this local git directory instead of cloning again from
> 6c6
> < or you are unsure what this means choose another name with the '--name' option.
> ---
>> or if you are unsure what this means, choose another name with the '--name' option.
>
>
> The first part shows that it is additionally prefixed with 'fatal: '. While the 'fatal :' prefix
> made sense in other cases, I wonder if it's helpful in this case as the message being
> printed is an informative one. Should we avoid using 'die' to print this message?

I had initially implemented that message as an fprintf() with return for
the same reason, but Junio suggested we die() instead to keep the
conversion more faithful to the original [1].

Although now that I think of it, it feels like a tradeoff between
faithfulness to the original code and faithfulness to the original
behaviour. I also think this change is fairly inconsequential and easily
reversible so I am fine with it being done either way.

[1] https://lore.kernel.org/git/[email-masked]/

> The second part of the diff shows that there's some small grammatcial tweaks in the last
> line. While I appreciate the intention, I'm not very sure if this change is a strict
> improvement. I wonder about this as the original sounded good enough to me and thus it
> feels like the change in message is triggering unnecesssary translation work. Should
> we avoid the change? Or does it actually seem like an improvement to the message?

I don't think that extra 'if' was intended. I think it's better to avoid
the change I inadvertently introduced.

> builtin/submodule--helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 3cbde305f3..560be07091 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -2824,7 +2824,7 @@ static int add_submodule(const struct add_data *add_data)
>  		if (is_directory(submod_gitdir_path)) {
>  			if (!add_data->force) {
>  				fprintf(stderr, _("A git directory for '%s' is found "
> -						  "locally with remote(s):"),
> +						  "locally with remote(s):\n"),
>  					add_data->sm_name);
>  				show_fetch_remotes(stderr, add_data->sm_name,
>  						   submod_gitdir_path);
> @@ -2835,7 +2835,7 @@ static int add_submodule(const struct add_data *add_data)
>  				      "use the '--force' option. If the local git "
>  				      "directory is not the correct repo\n"
>  				      "or if you are unsure what this means, choose "
> -				      "another name with the '--name' option.\n"),
> +				      "another name with the '--name' option."),
>  				    add_data->realrepo);
>  			} else {
>  				printf(_("Reactivating local git directory for "

---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर