Victor Leschuk <vlesc...@gmail.com> writes:
> Maybe it'll make sense to modify file_exists() to treat ":/"
> specially.
The real problem is that the code assumes that it can internally use
":/" to mean "everything from the top", and with global 'literal
pathspec' magic, that is not the case. "did not match" is a red
herring. Even if you disable that typo-catcher, the resulting
pathspec will match only paths inside a directory whose name is ':',
so you would break 'add -u' in a more grave way.
Disabling the typo-catcher has another problem. When an end user
says "git --literal-pathspecs add -u :/", the user means "I happen
to have this funnily named directory ':' and want to update
everything under it, but because :/ is normally taken as special, I
am passing --literal-pathspecs". And if that ':' does not exist,
the user must get the "well you may have misspelt it" error.
But a code you are changing cannot tell if ":/" came from the end
user, or if it the one added by our code upon seeing "-u" or "-A"
without any pathspecs, to make that distinction so that you disable
it only for our internal ":/".
I think the right approach is something along the line of this patch
instead.
-- >8 --
Subject: add: simplify -u/-A without pathspec
Since Git 2.0, "add -u" and "add -A" run from a subdirectory without
any pathspec mean "everything in the working tree" (before 2.0, they
were limited to the current directory). The limiting to the current
directory was implemented by inserting "." to the command line when
the end user did not give us any pathspec. At 2.0, we updated the
code to insert ":/" (instead of '.') to consider everything from the
top-level, by using a pathspec magic "top".
The call to parse_pathspec() using the command line arguments is,
however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add:
convert to use parse_pathspec, 2013-07-14), which predates Git 2.0.
In retrospect, there was no need to turn "adding . to limit to the
directory" into "adding :/ to unlimit to everywhere" in Git 2.0;
instead we could just have done "if there is no pathspec on the
command line, just let it be". The parse_pathspec() then would give
us a pathspec that matches everything and all is well.
Incidentally such a simplifcation also fixes a corner case bug that
stems from the fact that ":/" does not necessarily mean any magic.
A user would say "git --literal-pathspecs add -u :/" from the
command line when she has a directory ':' and wants to add
everything in it (and she knows that her :/ will be taken as
'everything under the sun' magic pathspec unless she disables the
magic with --literal-pathspecs). The internal use of ':/' would
behave the same way as such an explicitly given ":/" when run with
"--literal-pathspecs", and will not add everything under the sun as
the code originally intended.
Signed-off-by: Junio C Hamano <gits...@pobox.com>
---
builtin/add.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index b2a5c57..145f06e 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -336,14 +336,8 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with
--dry-run"));
- if ((0 < addremove_explicit || take_worktree_changes) && !argc) {
- static const char *whole[2] = { ":/", NULL };
- argc = 1;
- argv = whole;
- }
-
add_new_files = !take_worktree_changes && !refresh_only;
- require_pathspec = !take_worktree_changes;
+ require_pathspec = !(take_worktree_changes || (0 < addremove_explicit));
hold_locked_index(&lock_file, 1);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
