Re: [PATCH] completion: bash: support recursive aliases

[Jeff King <peff@peff.net>]

On Mon, Nov 09, 2020 at 03:52:48PM -0600, Felipe Contreras wrote:

> It is possible to have a recursive aliases like:
> 
>   l = log --oneline
>   lg = l --graph
> 
> So the completion should detect such aliases as well.

Yeah, agreed that it would be nice to handle this case.

>  __git_aliased_command ()
>  {
> [...]
> +	if [[ -n "$found" ]]; then
> +		local expansion=$(__git_aliased_command "$found")
> +		echo "${expansion:-$found}"
> +	fi

So if we expanded X to Y, we recurse and try to expand Y. That makes
sense, but just thinking of some possible drawbacks:

 - it's an extra process invocation for each alias lookup (to see "nope,
   this doesn't expand further"). That's probably OK, since this is
   triggered by human action.

   I don't think there's a way to avoid this with the current set of Git
   commands. "git help lg" isn't recursive, and anyway isn't suitable
   for general use (if there is no such alias, it tries to load the
   manpage!).

 - there's no limit on the recursion if we do see a cycle. Doing:

     git config alias.foo foo
     git foo <Tab>

   seems to fork-bomb the system with bash processes (well, perhaps not
   a true fork-bomb because they expand linearly rather than
   exponentially, but still...).

   That's obviously a broken and useless, but the outcome is less than
   ideal.  We could avoid it by looking for repeats in the chain. Doing
   so in posix shell is pretty painful, but perhaps bash associate
   arrays would make it not too painful.

We do have "git <cmd> --git-completion-helper" these days. I wonder if
something like "git --expand-alias-to-command" would be a useful
addition, as it would let us directly ask which Git command would be
executed (if any). And it would make both downsides go away.

I don't mind this solution in the meantime, though.

-Peff