From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@inf.ethz.ch>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)
Date: Thu, 18 Apr 2013 13:27:14 -0400 [thread overview]
Message-ID: <20130418172714.GA24690@sigill.intra.peff.net> (raw)
In-Reply-To: <7va9owd3d1.fsf@alter.siamese.dyndns.org>
On Wed, Apr 17, 2013 at 06:39:06PM -0700, Junio C Hamano wrote:
> Subject: [PATCH] git add: rework the logic to warn "git add <pathspec>..." default change
>
> [...]
>
> Rework the logic to detect the case where the behaviour will be
> different in Git 2.0, and issue a warning only when it matters.
> Even with the code before this warning, "git add subdir" will have
> to traverse the directory in order to find _new_ files the index
> does not know about _anyway_, so we can do this check without adding
> an extra pass to find if <pathspec> matches any removed file.
Thanks, I think this is looking much better.
A few minor nits on the message itself:
> +static void warn_add_would_remove(const char *path)
> +{
> + warning(_("In Git 2.0, 'git add <pathspec>...' will also update the\n"
> + "index for paths removed from the working tree that match\n"
> + "the given pathspec. If you want to 'add' only changed\n"
> + "or newly created paths, say 'git add --no-all <pathspec>...'"
> + " instead.\n\n"
This wrapping looks funny in the actual output, due to the extra
"warning:" and the lack of newline before "instead":
warning: In Git 2.0, 'git add <pathspec>...' will also update the
index for paths removed from the working tree that match
the given pathspec. If you want to 'add' only changed
or newly created paths, say 'git add --no-all <pathspec>...' instead.
Wrapping it like this ends up with a much more natural-looking
paragraph:
warning: In Git 2.0, 'git add <pathspec>...' will also update the
index for paths removed from the working tree that match the given
pathspec. If you want to 'add' only changed or newly created paths,
say 'git add --no-all <pathspec>...' instead.
> + "'%s' would be removed from the index without --no-all."),
> + path);
I think mentioning the filename is a good thing; the original message
left me scratching my head and wondering "so, did you add it or not?".
I still think your "would be" is unnecessarily confusing, though. It is
"would be in Git 2.0 without --no-all, but we did not now". Which makes
sense when you think about it, but it took me a moment to parse.
Perhaps we can be more direct with something like:
warning: did not stage removal of 'foo'
or perhaps the present tense "not staging removal of..." would be
better.
I also think it makes sense to show every path that is affected, not
just the first one, to be clear about what was done (and what _would_
have been done in Git 2.0).
A patch with all of the suggestions together is below. I still think the
multi-line warning block looks ugly. I kind of like the way advise()
puts "hint:" on each line. I wonder if we should do the same here.
diff --git a/builtin/add.c b/builtin/add.c
index 4242bce..aae550a 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -52,15 +52,19 @@ static void warn_add_would_remove(const char *path)
return DIFF_STATUS_MODIFIED;
}
+static const char *add_would_remove_warning = N_(
+/* indent for "warning: " */
+ "In Git 2.0, 'git add <pathspec>...' will also update the\n"
+"index for paths removed from the working tree that match the given\n"
+"pathspec. If you want to 'add' only changed or newly created paths,\n"
+"say 'git add --no-all <pathspec>...' instead.\n");
+
static void warn_add_would_remove(const char *path)
{
- warning(_("In Git 2.0, 'git add <pathspec>...' will also update the\n"
- "index for paths removed from the working tree that match\n"
- "the given pathspec. If you want to 'add' only changed\n"
- "or newly created paths, say 'git add --no-all <pathspec>...'"
- " instead.\n\n"
- "'%s' would be removed from the index without --no-all."),
- path);
+ static int warned_once;
+ if (!warned_once++)
+ warning(_(add_would_remove_warning));
+ warning("did not stage removal of '%s'", path);
}
static void update_callback(struct diff_queue_struct *q,
@@ -84,10 +88,8 @@ static void update_callback(struct diff_queue_struct *q,
}
break;
case DIFF_STATUS_DELETED:
- if (data->warn_add_would_remove) {
+ if (data->warn_add_would_remove)
warn_add_would_remove(path);
- data->warn_add_would_remove = 0;
- }
if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
break;
if (!(data->flags & ADD_CACHE_PRETEND))
next prev parent reply other threads:[~2013-04-18 17:27 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 20:28 What's cooking in git.git (Apr 2013, #05; Mon, 15) Junio C Hamano
2013-04-15 22:24 ` Felipe Contreras
2013-04-15 23:14 ` Junio C Hamano
2013-04-15 23:30 ` Felipe Contreras
2013-04-16 4:12 ` Junio C Hamano
2013-04-16 5:32 ` Felipe Contreras
2013-04-16 9:59 ` Thomas Rast
2013-04-16 19:04 ` Felipe Contreras
2013-04-16 19:19 ` Junio C Hamano
2013-04-16 19:48 ` Felipe Contreras
2013-04-16 22:34 ` Phil Hord
2013-04-16 23:50 ` Felipe Contreras
2013-04-16 22:45 ` Phil Hord
2013-04-17 4:44 ` Junio C Hamano
2013-04-17 18:50 ` Felipe Contreras
2013-04-17 23:56 ` Junio C Hamano
2013-04-18 3:59 ` Felipe Contreras
2013-04-18 7:44 ` Matthieu Moy
2013-04-18 9:15 ` Felipe Contreras
2013-04-18 9:19 ` Ramkumar Ramachandra
2013-04-18 9:53 ` Felipe Contreras
2013-04-18 10:27 ` Ramkumar Ramachandra
2013-04-18 10:55 ` Felipe Contreras
2013-04-18 11:31 ` Ramkumar Ramachandra
2013-04-18 12:05 ` Felipe Contreras
2013-04-18 11:46 ` Ramkumar Ramachandra
2013-04-18 12:16 ` Felipe Contreras
2013-04-23 18:49 ` Ramkumar Ramachandra
2013-04-23 19:11 ` Felipe Contreras
2013-04-18 20:06 ` Phil Hord
2013-04-18 23:48 ` Felipe Contreras
2013-04-19 21:07 ` Phil Hord
2013-04-20 1:29 ` Felipe Contreras
2013-04-15 23:25 ` Jeff King
2013-04-15 23:49 ` Øyvind A. Holm
2013-04-16 0:53 ` Jeff King
2013-04-16 0:30 ` Jeff King
2013-04-16 1:08 ` Eric Sunshine
2013-04-16 17:18 ` Junio C Hamano
2013-04-16 3:21 ` Drew Northup
2013-04-16 23:52 ` "What's cooking" between #05 and #06 Junio C Hamano
2013-04-17 8:40 ` John Keeping
2013-04-17 15:30 ` Junio C Hamano
2013-04-17 21:25 ` Jens Lehmann
2013-04-18 8:49 ` John Keeping
2013-04-17 8:49 ` What's cooking in git.git (Apr 2013, #05; Mon, 15) Lukas Fleischer
2013-04-17 15:11 ` Junio C Hamano
2013-04-17 9:47 ` Thomas Rast
2013-04-17 15:24 ` Junio C Hamano
2013-04-17 15:56 ` Thomas Rast
2013-04-17 17:08 ` Junio C Hamano
2013-04-17 18:14 ` Junio C Hamano
2013-04-17 20:10 ` Jeff King
2013-04-18 1:39 ` Junio C Hamano
2013-04-18 1:47 ` [PATCH] git add <pathspec>... defaults to "-A" Junio C Hamano
2013-04-18 17:27 ` Jeff King [this message]
2013-04-18 17:51 ` What's cooking in git.git (Apr 2013, #05; Mon, 15) Junio C Hamano
2013-04-18 18:00 ` Jeff King
2013-04-18 18:16 ` Junio C Hamano
2013-04-18 20:30 ` Jeff King
2013-04-18 21:37 ` Junio C Hamano
2013-04-18 21:44 ` Jeff King
2013-04-18 22:10 ` Junio C Hamano
2013-04-19 4:14 ` Jeff King
2013-04-19 4:31 ` Jonathan Nieder
2013-04-19 17:25 ` Junio C Hamano
2013-04-19 21:34 ` Jeff King
2013-04-19 21:56 ` Junio C Hamano
2013-04-21 7:39 ` jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)) Jonathan Nieder
2013-04-22 1:51 ` Junio C Hamano
2013-04-22 4:54 ` Junio C Hamano
2013-04-22 20:43 ` [PATCH 0/2] "git add -A/--no-all" finishing touches Junio C Hamano
2013-04-22 20:43 ` [PATCH 1/2] git add: --ignore-removal is a better named --no-all Junio C Hamano
2013-04-22 20:43 ` [PATCH 2/2] git add: rephrase -A/--no-all warning Junio C Hamano
2013-04-22 22:41 ` [PATCH 3/2] git add <pathspec>... defaults to "-A" Junio C Hamano
2013-04-23 0:42 ` Eric Sunshine
2013-04-25 23:06 ` [PATCH 0/2] "git add -A/--no-all" finishing touches Junio C Hamano
2013-04-25 23:19 ` Junio C Hamano
2013-04-25 23:24 ` Jonathan Nieder
2013-04-25 23:41 ` Junio C Hamano
2013-04-25 23:44 ` Junio C Hamano
2013-04-25 23:56 ` Jonathan Nieder
2013-04-26 0:14 ` Junio C Hamano
2013-04-26 20:44 ` Junio C Hamano
2013-04-26 21:30 ` Jonathan Nieder
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=20130418172714.GA24690@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@inf.ethz.ch \
/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 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 NNTP newsgroup(s).