Quoting Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>:
SZEDER Gábor venit, vidit, dixit 05.10.2015 14:02:
The main completion function finds the name of the git command by
iterating through all the words on the command line in search for the
first non-option-looking word. As it is not aware of 'git -C's
mandatory path argument, if the '-C path' option is present, 'path' will
be the first such word and it will be mistaken for a git command. This
breaks the completion script in various ways:
- If 'path' happens to match one of the commands supported by the
completion script, then its options will be offered.
- If 'path' doesn't match a supported command and doesn't contain any
characters not allowed in Bash identifier names, then the completion
script does basically nothing and lets Bash to fall back to filename
completion.
- Otherwise, if 'path' contains such unallowed characters, then it
leads to a more or less ugly error in the middle of the command line.
The standard '/' directory separator is such a character, and it
happens to trigger one of the uglier errors:
$ git -C some/path <TAB>sh.exe": declare: `_git_some/path':
not a valid identifier
error: invalid key: alias.some/path
Fix this by skipping 'git -C's mandatory path argument while iterating
over the words on the command line. Extend the relevant test with this
case and, while at it, with cases that needed similar treatment in the
past ('--git-dir', '-c', '--work-tree' and '--namespace').
Additionally, shut up standard error of the 'declare' commands looking
for the associated completion function and of the 'git config' query for
the aliased command, so if git learns a new option with a mandatory
argument in the future, then at least the command line will not be
utterly disrupted by those error messages.
Note, that this change merely fixes the breakage related to 'git -C
path', but the completion script will not take it into account as it
does '--git-dir path'.
I don't understand the "as it does" part. Do you mean that the
completion script does '--git-dir path', or that git does it?
When the user specifies '--git-dir path' on the command line the
completion script respects that (most of the time, I noticed a few
missing spots), i.e.
git --git-dir /somewhere/else/.git log <TAB>
gives you all the refs from the specified repository, which is good.
However, that's not the case with '-C /somewhere/else', as it will lead to
the error mentioned in the commit message on current git, or will be
ignored with this patch.
In any case, "git -C path ..." is more like "cd path && git ...". That
is, completion should take it into account at least when determining
GIT_DIR (though -C does not specifiy the git-dir directly), and possibly
also for completion of untracked files. Otherwise, it's going by the
wrong repo (unless path is a subdir of cwd).
I agree, it should, but it doesn't. That will be the next step in some
future patches.
Gábor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html