From: SZEDER Gábor Date: Tue, 06 Oct 2015 10:12:24 GMT Subject: Re: [PATCH] completion: fix completion after 'git -C path' Message-ID: <20151006121224.Horde.eFfzROzl5PskJn4vxQYePQ6@webmail.informatik.kit.edu> In-Reply-To: <56138BB7.4000404@drmicha.warpmail.net> Quoting Michael J Gruber : > 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 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 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