From: Junio C Hamano <gitster@pobox.com>
To: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Cc: git@vger.kernel.org,
Jorge Juan Garcia Garcia
<Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v3 1/2] rm: better error message on failure for multiple files
Date: Mon, 10 Jun 2013 10:17:47 -0700 [thread overview]
Message-ID: <7v8v2hkhqc.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1370879981-18937-1-git-send-email-Mathieu.Lienard--Mayor@ensimag.imag.fr> (Mathieu Lienard--Mayor's message of "Mon, 10 Jun 2013 17:59:40 +0200")
Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
writes:
> When 'git rm' fails, it now displays a single message
> with the list of files involved, instead of displaying
> a list of messages with one file each.
>
> As an example, the old message:
> error: 'foo.txt' has changes staged in the index
> (use --cached to keep the file, or -f to force removal)
> error: 'bar.txt' has changes staged in the index
> (use --cached to keep the file, or -f to force removal)
>
> would now be displayed as:
> error: the following files have changes staged in the index:
> foo.txt
> bar.txt
> (use --cached to keep the file, or -f to force removal)
>
> Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
> ---
>
> Changes since v2:
> -couple typo in commit message and in code
> -rename and redefinition of the intermediate function
> -move the 4 "if(....nr)" inside the function
>
> builtin/rm.c | 71 +++++++++++++++++++++++++++++++++++++++++++++-----------
> t/t3600-rm.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 124 insertions(+), 14 deletions(-)
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index 7b91d52..07306eb 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -70,6 +70,24 @@ static int check_submodules_use_gitfiles(void)
> return errs;
> }
>
> +static void print_eventual_error_files(struct string_list *files_list,
> + const char *main_msg,
> + const char *hints_msg,
> + int *errs)
Hrm, I do not see the point of "eventual" there, by the way. Are
there other kinds of error files?
> +{
> + if (files_list->nr) {
> + struct strbuf err_msg = STRBUF_INIT;
> + int i;
> + strbuf_addstr(&err_msg, main_msg);
> + for (i = 0; i < files_list->nr; i++)
> + strbuf_addf(&err_msg,
> + "\n %s",
Is there an implication of having always 4 spaces here to l10n/i18n
here? I am wondering if it should be _("\n %s").
> + files_list->items[i].string);
> + strbuf_addstr(&err_msg, hints_msg);
> + *errs = error("%s", err_msg.buf);
There needs a strbuf_release(&err_msg) somewhere before leaving this
scope to avoid leaking its buffer, no?
> + }
> +}
> +
> static int check_local_mod(unsigned char *head, int index_only)
> {
> /*
> @@ -82,6 +100,11 @@ static int check_local_mod(unsigned char *head, int index_only)
> int i, no_head;
> int errs = 0;
>
> + struct string_list files_staged = STRING_LIST_INIT_NODUP;
> + struct string_list files_cached = STRING_LIST_INIT_NODUP;
> + struct string_list files_submodule = STRING_LIST_INIT_NODUP;
> + struct string_list files_local = STRING_LIST_INIT_NODUP;
> +
> no_head = is_null_sha1(head);
> for (i = 0; i < list.nr; i++) {
> struct stat st;
> @@ -171,29 +194,49 @@ static int check_local_mod(unsigned char *head, int index_only)
> */
> if (local_changes && staged_changes) {
> if (!index_only || !(ce->ce_flags & CE_INTENT_TO_ADD))
> + string_list_append(&files_staged, name);
> }
> else if (!index_only) {
> if (staged_changes)
> - errs = error(_("'%s' has changes staged in the index\n"
> - "(use --cached to keep the file, "
> - "or -f to force removal)"), name);
> + string_list_append(&files_cached, name);
> if (local_changes) {
> if (S_ISGITLINK(ce->ce_mode) &&
> !submodule_uses_gitfile(name)) {
> + string_list_append(&files_submodule,
> + name);
> + } else {
> + string_list_append(&files_local, name);
> + }
The innermost if/else no longer needs braces. Also even though it
may push it slightly over 80-column, I think the files_submodule
side of string_list_append() is easier to read if it were on a
single line.
> + print_eventual_error_files(&files_staged,
> + _("the following files have staged "
> + "content different from both the"
> + "\nfile and the HEAD:"),
> + _("\n(use -f to force removal)"),
> + &errs);
Hmph. I wonder if we want to properly i18n plurals, depending on
the number of files, e.g.
print_error_files(&files_staged,
Q_("the following file has staged "
"content different from both the\n"
"file and the HEAD:",
"the following files have staged "
"content different from both the\n"
"file and the HEAD:", files_staged.nr),
_("\n(use -f to force removal)"), &errs);
This was not a problem back when we showed one error message per one
path, but with this patch, it starts to matter.
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> index 0c44e9f..10dd380 100755
> --- a/t/t3600-rm.sh
> +++ b/t/t3600-rm.sh
> @@ -687,4 +687,71 @@ test_expect_failure SYMLINKS 'rm across a symlinked leading path (w/ index)' '
> test_path_is_file e/f
> '
>
> +test_expect_success 'setup for testing rm messages' '
> + >bar.txt &&
> + >foo.txt &&
> + git add bar.txt foo.txt
> +'
> +
> +test_expect_success 'rm files with different staged content' '
> + cat >expect << EOF &&
> +error: the following files have staged content different from both the
> +file and the HEAD:
> + bar.txt
> + foo.txt
> +(use -f to force removal)
> +EOF
> + echo content1 >foo.txt &&
It is easier to read if it is done this way:
test_expect_success 'rm files with different staged content' '
cat >expect <<\-EOF &&
error: the following files have staged content different from both the
file and the HEAD:
bar.txt
foo.txt
(use -f to force removal)
EOF
echo content1 >foo.txt &&
Two and half points to note:
(0) no whitespace between redirection << and its source
(the end-of-here-text marker in this case).
(1) by quoting the end-of-here-text marker with a backslash '\',
you tell the readers that there is no variable substitution in
it, which reduces the mental burden on them.
(2) by using a dash '-' before the end-of-here-text marker, you can
align the body of here text with a leading tab (HT).
> + echo content1 >bar.txt &&
> + test_must_fail git rm foo.txt bar.txt 2>actual &&
> + test_cmp expect actual
This should be test_i18ncmp as the error messages are marked for
l10n.
Other than that, looks nicely done.
> +'
> +
> +
> +test_expect_success 'rm file with local modification' '
> + cat >expect << EOF &&
> +error: the following files have local modifications:
> + foo.txt
> +(use --cached to keep the file, or -f to force removal)
> +EOF
> + git commit -m "testing rm 3" &&
> + echo content3 >foo.txt &&
> + test_must_fail git rm foo.txt 2>actual &&
> + test_cmp expect actual
> +'
> +
> +
> +test_expect_success 'rm file with changes in the index' '
> + cat >expect << EOF &&
> +error: the following files have changes staged in the index:
> + foo.txt
> +(use --cached to keep the file, or -f to force removal)
> +EOF
> + git reset --hard &&
> + echo content5 >foo.txt &&
> + git add foo.txt &&
> + test_must_fail git rm foo.txt 2>actual &&
> + test_cmp expect actual
> +'
> +
> +
> +test_expect_success 'rm files with two different errors' '
> + cat >expect << EOF &&
> +error: the following files have staged content different from both the
> +file and the HEAD:
> + foo1.txt
> +(use -f to force removal)
> +error: the following files have changes staged in the index:
> + bar1.txt
> +(use --cached to keep the file, or -f to force removal)
> +EOF
> + echo content >foo1.txt &&
> + git add foo1.txt &&
> + echo content6 >foo1.txt &&
> + echo content6 >bar1.txt &&
> + git add bar1.txt &&
> + test_must_fail git rm bar1.txt foo1.txt 2>actual &&
> + test_cmp expect actual
> +'
> +
> test_done
next prev parent reply other threads:[~2013-06-10 17:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 15:59 [PATCH v3 1/2] rm: better error message on failure for multiple files Mathieu Lienard--Mayor
2013-06-10 15:59 ` [PATCH v3 2/2] rm: introduce advice.rmHints to shorten messages Mathieu Lienard--Mayor
2013-06-10 17:25 ` Junio C Hamano
2013-06-10 16:06 ` [PATCH v3 1/2] rm: better error message on failure for multiple files Matthieu Moy
2013-06-10 17:17 ` Junio C Hamano [this message]
2013-06-10 17:42 ` Matthieu Moy
2013-06-10 20:55 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2013-06-10 16:05 Mathieu Lienard--Mayor
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=7v8v2hkhqc.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Jorge-Juan.Garcia-Garcia@ensimag.imag.fr \
--cc=Mathieu.Lienard--Mayor@ensimag.imag.fr \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
/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).