All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jiang Xin <worldhello.net@gmail.com>
Cc: git@vger.kernel.org
Subject: [PATCH] commit: do not use cryptic "new_index" in end-user facing messages
Date: Tue, 17 Oct 2023 20:08:51 -0700	[thread overview]
Message-ID: <xmqqo7gwvd8c.fsf_-_@gitster.g> (raw)
In-Reply-To: <xmqqwmvkve83.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 17 Oct 2023 19:47:24 -0700")

These error messages say "new_index" as if that spelling has some
significance to the end users (e.g. the file "$GIT_DIR/new_index"
has some issues), but that is not the case at all.  The i18n folks
were made to include the word literally in the translated messages,
which was not a good idea at all.  Spell it "new index", as we are
just telling the users that we failed to create a new index file.
The term is expected to be translated to the end-users' languages,
not left as if it were a literal file name.

This dates all the way back to the first re-implemenation of "git
commit" command in C (the scripted version did not have such wording
in its error messages), in f5bbc322 (Port git commit to C.,
2007-11-08).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

    Junio C Hamano <gitster@pobox.com> writes:

    > Jiang Xin <worldhello.net@gmail.com> writes:
    > ...
    > Wait.  Is this supposed to be a good example of validator working
    > well?  We use this exact message three times in builtin/commit.c; is
    > the validator insisting on the translated message to have verbatim
    > string "new_index" in it so that the end-users will see it?
    > ...
    > I'd suggest doing s/new_index/new index/ to msgid string for these
    > anyway.

    Just so that we do not forget, in case my "using new_index in
    the message is wrong" is not my misunderstanding, here is such a
    patch.  Note that "checkout", "clone", "read-tree", and "stash"
    all use the "new index" spelling so this is not introducing any
    new message.  "git merge" and "git pull" that fast-forward also
    use this same message when they cannot write a new index file.

 builtin/commit.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 985a0445b7..7abd566bc7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -446,7 +446,7 @@ static const char *prepare_index(const char **argv, const char *prefix,
 		refresh_cache_or_die(refresh_flags);
 		cache_tree_update(&the_index, WRITE_TREE_SILENT);
 		if (write_locked_index(&the_index, &index_lock, 0))
-			die(_("unable to write new_index file"));
+			die(_("unable to write new index file"));
 		commit_style = COMMIT_NORMAL;
 		ret = get_lock_file_path(&index_lock);
 		goto out;
@@ -470,7 +470,7 @@ static const char *prepare_index(const char **argv, const char *prefix,
 			cache_tree_update(&the_index, WRITE_TREE_SILENT);
 		if (write_locked_index(&the_index, &index_lock,
 				       COMMIT_LOCK | SKIP_IF_UNCHANGED))
-			die(_("unable to write new_index file"));
+			die(_("unable to write new index file"));
 		commit_style = COMMIT_AS_IS;
 		ret = get_index_file();
 		goto out;
@@ -518,7 +518,7 @@ static const char *prepare_index(const char **argv, const char *prefix,
 	refresh_index(&the_index, REFRESH_QUIET, NULL, NULL, NULL);
 	cache_tree_update(&the_index, WRITE_TREE_SILENT);
 	if (write_locked_index(&the_index, &index_lock, 0))
-		die(_("unable to write new_index file"));
+		die(_("unable to write new index file"));
 
 	hold_lock_file_for_update(&false_lock,
 				  git_path("next-index-%"PRIuMAX,
@@ -1852,7 +1852,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 
 	if (commit_index_files())
 		die(_("repository has been updated, but unable to write\n"
-		      "new_index file. Check that disk is not full and quota is\n"
+		      "new index file. Check that disk is not full and quota is\n"
 		      "not exceeded, and then \"git restore --staged :/\" to recover."));
 
 	git_test_write_commit_graph_or_die();
-- 
2.42.0-398-ga9ecda2788


  reply	other threads:[~2023-10-18  3:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17 21:09 Is there any interest in localizing term delimiters in git messages? Alexander Shopov
2023-10-17 21:49 ` Junio C Hamano
2023-10-18  2:01   ` Jiang Xin
2023-10-18  2:47     ` Junio C Hamano
2023-10-18  3:08       ` Junio C Hamano [this message]
2023-10-19  5:08       ` Jiang Xin
2023-10-19 17:52         ` Junio C Hamano
2023-10-19 18:07           ` Jeff Hostetler
2023-10-19 19:18             ` Junio C Hamano
2023-10-19 19:47           ` Torsten Bögershausen
2023-10-19 20:16             ` Junio C Hamano
2023-10-21  9:30 ` Peter Krefting

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

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

  git send-email \
    --in-reply-to=xmqqo7gwvd8c.fsf_-_@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.