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 useful. > but we can later extend it to help "git help lgF" Yeah, this is a good idea. > and > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html