Junio C Hamano wrote:
> Because the implementation is too ugly.
I know :) The only reason I sent it with code is because I didn't get
any responses to an email without code. If you agree that it is a
useful feature, we have to figure out a beautiful implementation.
> I would however can imagine an alternative implementation which
> might be more palatable. It may go like this:
> [alias "lgF"]
> command = "log --oneline --boundary --first-parent"
> help = "show the first parent chain, one line per commit"
I'm not sure what value this adds. If I ever forget what my alias is
called, I `git rp --help` to get the expansion and then look up the
manpage. It would be ideal if I could `man git lgF` though: I'm sick
of having to type out `man git for-each-ref` everytime I need the
manpage for fer (obviously an unscripted `man` won't work: `git help`
will do the translation).
> completion = log
Again, unsure what value it adds. I already have plenty of aliases
that complete fine. The completion only fails if I have an !-command;
in that case, this solution is a hack: we should work towards not
requiring an !-command in the first place.
> so that not just alias.c code can take notice of alias.lgF.command
> to expand it,
How? Fundamentally, alias_lookup_cb() is a fired off by the
config-parsing infrastructure which calls a tolower() on everything:
alias.c has control over nothing, unless we re-implement the entire
config-parsing infrastructure specifically for aliases (Bad idea). I
don't see how changing from alias.<name> to alias.<name>.command helps
anything, especially when the other alias.<name>.* keys aren't even
> but we can later extend it to help "git help lgF"
Yeah, this is a good idea.
> bash/zsh completion (i.e. they would learn "lgF parameter would
> complete in a way similar to 'log'" from alias.lgF.completion).
Solved problem: see __git_aliased_command() in git-completion.bash.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html