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
