RFC patchcompletion: filter sources of git scripts from available commands

A bit of background first:

- The completion script gets the lists of available and porcelain git
  commands from the output of 'git help -a', which, besides the
  "official" git commands from $GIT_EXEC_PATH, includes all executables
  from $PATH whose name begins with 'git-'.  Great, this way the
  completion script can include the user's custom git commands that he
  dropped somewhere in his $PATH.

- The lists of available and porcelain git commands are not initialized
  when the completion script is sourced, but it's done lazily when the
  first git completion is performed.  Great, this way interactive shells
  start faster, see eaa4e6ee2a (Speed up bash completion loading,
  2009-11-17).

- MSysGit's /etc/profile by default includes the current working
  directory in $PATH.  Great, this way MSysGit Bash "mimics the Win32
  method of finding executables" (quoted from /etc/profile).

While all three things above are great by themselves, their combination, however, has unwanted side-effects: it makes the list of git commands non-deterministic on MSysGit, as it will depend on the current working directory where the first git completion is performed. Perhaps it's worst when it is performed at the top of a git.git clone because the source files of all git scripts are included in the lists of available and porcelain commands, about twenty, some of them not even sources of porcelains.

Possible solutions to avoid this issue are:

- Strip the current working directory from $PATH temporarily while we run
  'git help -a' to get all the available commands.  Care must be taken,
  because '.' can appear at the very beginning, end, or in the middle of
  $PATH, not to mention that on unixes it's unlikely but possible to have
  a directory containing e.g. ':.:' in the $PATH.

- Filter out scripts from the output of 'git help -a'.  This can be done
  by either
  * listing all possible script extensions, but this list will most likely
    never be complete, or
  * filtering out all commands containing a filename extension, i.e.
    anything with a '.' in it.
  This will bite users whose custom git commands have filename extensions,
  i.e. who put 'git-mycmd.sh' in '~/bin'.

Since this is an RFC, it goes with the last option, because that's the shortest and simplest.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

SZEDER Gábor <szeder@ira.uka.de> writes:

Would it be another option to re-evaluate the list upon chdir (we can trap an attempt to "cd", can't we?) _and_ if $PATH might contain ".". It is OK if the latter criterion is not precise as long as it does not say "$PATH does not have '.' in it" when it does.