Re: [PATCH v3] rev-parse: match @{upstream}, @{u} and @{push} case-insensitively

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> Before this change:
>>
>>     |----------------+-----+------+-----|
>>     | What?          | CI? | CIP? | AG? |
>>     |----------------+-----+------+-----|
>>     | sha1           | Y   | -    | N   |
>>     | describeOutput | N   | N    | N   |
>>     | refname        | N   | N    | N   |
>>     | @{<date>}      | Y   | Y    | Y   |
>>     | @{<n>}         | N/A | N/A  | N   |
>>     | @{-<n>}        | N/A | N/A  | N   |
>>     | @{upstream}    | N   | Y    | N   |
>>     | @{push}        | N   | Y    | N   |
>>     | ^{<type>}      | N   | Y    | N   |
>>     | ^{/regex}      | N   | N    | N   |
>>     |----------------+-----+------+-----|
>>
>> After it:
>>
>>     |----------------+-----+------+-----|
>>     | What?          | CI? | CIP? | AG? |
>>     |----------------+-----+------+-----|
>>     | sha1           | Y   | -    | N   |
>>     | describeOutput | N   | N    | N   |
>>     | refname        | N   | N    | N   |
>>     | @{<date>}      | Y   | Y    | Y   |
>>     | @{<n>}         | N/A | N/A  | N   |
>>     | @{-<n>}        | N/A | N/A  | N   |
>>     | @{upstream}    | Y   | -    | N   |
>>     | @{push}        | Y   | -    | N   |
>>     | ^{<type>}      | N   | Y    | N   |
>>     | ^{/regex}      | N   | N    | N   |
>>     |----------------+-----+------+-----|
>
> As we are not touching ^{<type>} or ^{/regex}, and it is obvious
> numbers do not have cases, I'll trim this down to focus only on
> things that are relevant while queuing:
>
>     Before this change:
>
>         |----------------+-----+------+-----|
>         | What?          | CI? | CIP? | AG? |
>         |----------------+-----+------+-----|
>         | @{<date>}      | Y   | Y    | Y   |
>         | @{upstream}    | N   | Y    | N   |
>         | @{push}        | N   | Y    | N   |
>         |----------------+-----+------+-----|
>
>     After it:
>
>         |----------------+-----+------+-----|
>         | What?          | CI? | CIP? | AG? |
>         |----------------+-----+------+-----|
>         | @{<date>}      | Y   | Y    | Y   |
>         | @{upstream}    | Y   | Y    | N   |
>         | @{push}        | Y   | Y    | N   |
>         |----------------+-----+------+-----|
>
> should be sufficient to highlight that it was possible to safely
> make these two things case insensitive, and we made so.
>
> For that matter, I do not know the value of AG? field---it only
> serves to show that @{<approxidate>} is an odd-man out and cannot be
> used as a good example to follow, but I am too lazy to remove it ;-)
>
>> Makes sense, replaced that note with that summary. Here's hopefully a
>> final v3 with that change. I've omitted the other two patches as noted
>> in the discussion about those two, I don't think it makes sense to
>> include them.
>
> Thanks.
>
>> @@ -122,6 +123,9 @@ refs/remotes/myfork/mybranch
>>  Note in the example that we set up a triangular workflow, where we pull
>>  from one location and push to another. In a non-triangular workflow,
>>  '@\{push}' is the same as '@\{upstream}', and there is no need for it.
>> ++
>> +This suffix is accepted when spelled in uppercase, and means the same
>> +thing no matter the case.
>
> As the above text (including the original) does not explicitly say
> that lowercase spelling is canonical, the new text is prone to be
> misinterpreted that only the uppercase version is accepted.  I'll
> do s/is accepted/is also accepted/ while queuing, but please holler
> if there are better ways to phrase this.