Re: [PATCH 0/2] Fix regression: CamelCased aliases
- Date: Fri, 14 Jul 2017 05:02:56 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH 0/2] Fix regression: CamelCased aliases
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. Prior to
v2.2.0 it did not, and it was "fixed" inadvertently by 111791559
(alias.c: replace `git_config()` with `git_config_get_string()`,
It's a known limitation of the alias config scheme that it cannot
distinguish between "camelcase" and "CamelCase" (nor represent commands
with underscores or other characters that are invalid in a keyname). In
the long run we'd want to allow "alias.CamelCase.command" or similar to
make this work correctly.
It probably doesn't hurt anything to make this old ambiguous style work
in the meantime if people are using it and finding it convenient.
> Johannes Schindelin (2):
> t1300: demonstrate that CamelCased aliases regressed
> alias: compare alias name *case-insensitively*
The patches look obviously correct.
As a meta-comment, I find splitting the tests from the fix like this
makes review more tedious. The commit messages have to repeat the exact
The only value I think it brings is that you can confirm in the
first commit that the expect_failure does indeed fail. I guess that has
some value, though I usually do it by running the test against the
version of git built from HEAD^.