Æ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.
Thanks.