Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 21, 2013, 20:31 UTC
Message-ID: <7vvc57kxxt.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kDDRicX9VmcRgG9daXVi6W-zGNt=x6ruy7X5MhrHOZbQ@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 13 quoted lines

> Junio C Hamano wrote:
>>> - rr/describe-contains-all at  $gmane/228278.
>>
>> This may overlap with a topic in flight (but I didn't look at it).
>
> Let me know if I can do anything to make it easier for you.  I'm quite
> excited about this one.
>
>>> - rr/mixed-case-aliases at $gmane/227959.
>>
>> Personally, not just uninterested but moderately against.
>
> Okay, but I'd like an explanation.

Because the implementation is too ugly.

The damage to the more generic config parser codepath is a real downside and the benefit from the little "feature" does not seem to justify it.

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"
		completion = log

so that not just alias.c code can take notice of alias.lgF.command to expand it, but we can later extend it to help "git help lgF" and bash/zsh completion (i.e. they would learn "lgF parameter would complete in a way similar to 'log'" from alias.lgF.completion).