On Mon, Mar 27, 2017 at 7:45 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
All of the above sounds good, thanks for fixing it up.