On Sun, Mar 19, 2017 at 10:19 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Sun, Mar 19, 2017 at 5:34 AM, Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
>> index ba11b9c95e..55bde6ea65 100644
>> --- a/Documentation/revisions.txt
>> +++ b/Documentation/revisions.txt
>> @@ -96,7 +96,8 @@ some output processing may assume ref names in UTF-8.
>> refers to the branch that the branch specified by branchname is set to build on
>> top of (configured with `branch.<name>.remote` and
>> `branch.<name>.merge`). A missing branchname defaults to the
>> - current one.
>> + current one. Both '@\{upstream\}', '@\{u\}' are case-insensitive, so e.g.
>> + '@\{UPSTREAM\}', '@\{U\}' or '@\{Upstream\}' also work.
>
> Since this change makes @{everything} case-insensitive and there's no
> new one on the horizon, can we just say "everything in @{..} is
> case-insensitive unless otherwise specified" and not updating every
> @{case}? It sets a new common rule for these @{}, which I think is
> good (easier to remember as a user).
I have a slight bias to keeping it the way it is, just because of the
distracted user in a hurry use-case that's looking up only @{u} and
not reading the manpage all the way through.
But yeah, I could do that, i.e. have some blurb at the top noting that
all of the magical syntax is case insensitive unless otherwise noted.
AFAICT the only thing that's case sensitive now is the ^{/regex} form.
Also an advantage of that would be that currently we don't note that
e.g. sha1s like dae86e aren't case sensitive and can be written like
DAE86E, and the @{<date>} syntax doesn't note that it's case
insensitive. A blurb at the top would cover that.