Re: [PATCH 0/2] Fix regression: CamelCased aliases
- From
Jeff King <peff@peff.net>
- Date
- Jul 14, 2017, 09:02 UTC
- Message-ID
- <20170714090256.ne4gqgppt2qshtak@sigill.intra.peff.net>
- In-Reply-To
- <cover.1500021526.git.johannes.schindelin@gmx.de>
On Fri, Jul 14, 2017 at 10:39:24AM +0200, Johannes Schindelin wrote:
Show 7 quoted lines
> 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()`, 2014-08-07).
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 same reasoning.
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^.
-Peff