Jeff King <peff@xxxxxxxx> writes:
> On Fri, Jul 14, 2017 at 10:39:24AM +0200, Johannes Schindelin wrote:
>
>> It was possible before v2.13.3 to invoke:
>>
>> git config alias.CamelCased <something>
>> git CamelCased
>>
>> This regressed (due to a stupid mistake of mine that was not caught in
>> patch review, sadly) in v2.13.3.
>
> Interesting. I don't think this was ever intended to work.
> ...
> The patches look obviously correct.
How can something be "(n)ever intended to work" and yet patches to
make it work be "obviously correct"? ;-)
My first/knee-jerk reation to the title of the series also was
"letter cases are not supposed to work in aliases", but that depends
on the definition of "work". When you add 'alias.Foo', you are not
supposed to be able to make 'git foo' behave differently from that
alias you defined. In order to make that, which is not supposed to
work, work, we'd need to introduce alias.Foo.commmand, as you said.
But I think that it is still reasonable for an end user to expect
that 'git Foo' would trigger that alias. And that is what was
recently changed, inadvertently.
So the problem may need to be explained better in this series, but I
think the usage was expected to work and the series is fixing a real
regression.
Do we want to promise to keep the following "working"?
git config alias.Foo <something>
git foo
By designing the system in such a way that an alias is created with
a two-level name in our system, we are saying that alias names are
case insensitive to the end users, so I _think_ the above is
intended to work, and we are effectively promising that it will keep
working.
It is a different matter if that design decision was sensible,
though.
> As a meta-comment, I find splitting the tests from the fix like this
> makes review more tedious.
I agree.
