git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Atharva Raykar <raykar.ath@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Christian Couder" <christian.couder@gmail.com>,
	"Shourya Shukla" <periperidip@gmail.com>,
	"Jiang Xin" <worldhello.net@gmail.com>
Subject: Re: [PATCH] submodule--helper: fix incorrect newlines in an error message
Date: Sat, 7 Aug 2021 00:37:55 +0530	[thread overview]
Message-ID: <1f7c1d28-4482-b6db-17f0-edbc6934acda@gmail.com> (raw)
In-Reply-To: <m28s1fuluy.fsf@gmail.com>

On 06/08/21 11:59 am, Atharva Raykar wrote:
> 
> Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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/20210710074801.19917-5-raykar.ath@gmail.com/#t
>>
>> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
>> ---
>>
>> 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/xmqqk0n03k84.fsf@gitster.g/
> 

I remember this discussion. But ...

   A git directory for 'subm' is found locally with remote(s):
      origin        /me/git-repos-for-test/sub
   fatal: If you want to reuse this local git directory instead of cloning again from
     /me/git-repos-for-test/sub
   use the '--force' option. If the local git directory is not the correct repo
   or you are unsure what this means choose another name with the '--name' option.

... I'm not able to understand how the 'fatal: ' prefix in the _middle_ of this
information message would help the reader in any way :-/

If it had occurred at the beginning of the message that would've been different
and likely useful too. I'll try sending a re-roll with a new change that moves
the fatal to the beginning of the message and see how it goes.

>> 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.
> 

I guess I spoke too soon. Regardless of the additional "... if ..." in the message,
the conversion might introduce translation work as the variable substitution varies
between shell and C. There isn't much we could do about this. I'm not sure if
translators use any strategy to avoid redundant work during conversions like these.
Jiang Xin (Cc-ed) might be able to shed some light.

That said, I'll still revert the extra 'if' as you say it was introduced inadvertently.

-- 
Sivaraam

  reply	other threads:[~2021-08-06 19:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-06 18:19 [GSoC] [PATCH 0/3] submodule add: partial conversion to C Atharva Raykar
2021-07-06 18:19 ` [GSoC] [PATCH 1/3] t7400: test failure to add submodule in tracked path Atharva Raykar
2021-07-06 18:19 ` [GSoC] [PATCH 2/3] submodule--helper: refactor module_clone() Atharva Raykar
2021-07-06 18:19 ` [GSoC] [PATCH 3/3] submodule--helper: introduce add-clone subcommand Atharva Raykar
2021-07-07 19:57   ` Junio C Hamano
2021-07-08  6:45     ` Atharva Raykar
2021-07-08  9:55 ` [GSoC] [PATCH v2 0/4] submodule add: partial conversion to C Atharva Raykar
2021-07-08  9:55   ` [GSoC] [PATCH v2 1/4] t7400: test failure to add submodule in tracked path Atharva Raykar
2021-07-08  9:55   ` [GSoC] [PATCH v2 2/4] submodule: prefix die messages with 'fatal' Atharva Raykar
2021-07-08 15:17     ` Junio C Hamano
2021-07-09 14:52     ` Đoàn Trần Công Danh
2021-07-10  7:52       ` Atharva Raykar
2021-07-10 12:04         ` Kaartic Sivaraam
2021-07-08  9:55   ` [GSoC] [PATCH v2 3/4] submodule--helper: refactor module_clone() Atharva Raykar
2021-07-08  9:55   ` [GSoC] [PATCH v2 4/4] submodule--helper: introduce add-clone subcommand Atharva Raykar
2021-07-10  7:47   ` [GSoC] [PATCH v3 0/4] submodule add: partial conversion to C Atharva Raykar
2021-07-10  7:47     ` [GSoC] [PATCH v3 1/4] t7400: test failure to add submodule in tracked path Atharva Raykar
2021-07-10  7:47     ` [GSoC] [PATCH v3 2/4] submodule: prefix die messages with 'fatal' Atharva Raykar
2021-07-10  7:48     ` [GSoC] [PATCH v3 3/4] submodule--helper: refactor module_clone() Atharva Raykar
2021-07-10  7:48     ` [GSoC] [PATCH v3 4/4] submodule--helper: introduce add-clone subcommand Atharva Raykar
2021-07-23 11:12       ` [PATCH] submodule: drop unused sm_name parameter from show_fetch_remotes() Jeff King
2021-07-23 17:12         ` Atharva Raykar
2021-07-26 19:03           ` Junio C Hamano
2021-08-05 19:28       ` [PATCH] submodule--helper: fix incorrect newlines in an error message Kaartic Sivaraam
2021-08-06  6:29         ` Atharva Raykar
2021-08-06 19:07           ` Kaartic Sivaraam [this message]
2021-09-18 19:31         ` [PATCH v2 0/1] submodule: corret an incorrectly formatted " Kaartic Sivaraam
2021-09-18 19:31           ` [PATCH v2 1/1] submodule--helper: fix incorrect newlines in an " Kaartic Sivaraam
2021-09-20 18:09             ` Junio C Hamano
2021-09-21 16:52               ` Atharva Raykar
2021-09-21 16:47             ` Atharva Raykar
2021-10-23 12:57               ` [PATCH v3 0/1] submodule: correct an incorrectly formatted " Kaartic Sivaraam
2021-10-23 12:57                 ` [PATCH v3 1/1] submodule--helper: fix incorrect newlines in an " Kaartic Sivaraam
2021-10-24  6:05                 ` [PATCH v3 0/1] submodule: correct an incorrectly formatted " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f7c1d28-4482-b6db-17f0-edbc6934acda@gmail.com \
    --to=kaartic.sivaraam@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=periperidip@gmail.com \
    --cc=raykar.ath@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=worldhello.net@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).