Re: [PATCH v5] git-prompt: make colourization consistent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/06/2022 18:04, Junio C Hamano wrote:
Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes:

On 6/5/22 02:26, Joakim Petersen wrote:
If the user is in a sparse checkout, the sparsity state indicator
follows a similar pattern to the short upstream state indicator.
However, clearing colour of the colourized indicators changes how the
sparsity state indicator is colourized , as it currently inherits (and
before the change referenced also inherited) the colour of the last
short state indicator before it. Reading the commit message of the
change that introduced the sparsity state indicator, afda36dbf3b
(git-prompt: include sparsity state as well, 2020-06-21), it appears
this colourization also was unintended, so clearing the colour for said
indicator further increases consistency.


colourization? I have never heared that. Did you mean "colorization" (en-US)
or "colourisation" (en-UK)? I assumed the former.

;-)

Either way, that word is a mouthful.  Using verb "to color" and
"coloring" might be easier to read, perhaps?


I went with "colourization" as that is what the process is referred to
in the code, however, I do agree it is a mouthful compared to "colour".
Since I'm already submitting a v8 for other reasons, I'll make this
change in the message as well.

Since the comment about the choice of suffix spelling got picked up,
I'll repeat what I told Bagas off list: "-ize" being American English
is a misconception; most uses of "z" instead of "s" are AE, but the verb
suffix is closer to its origin in Greek with "z", and is preferred by
Oxford for this reason.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux