Please, paint new branch errors in RED (or any visible color)

Please, paint new branch errors in RED (or any visible color)

[Jose Wielandt]

Hi community,

At my work we've been struggling a lot with not realizing that our new
branch creation actually failed, ending up with a push directly to
develop. What are those cases?

$ git checkout -b feature/solve p-eq-np
fatal: Cannot update paths and switch to branch 'feature/solve' at the
same time.

What's my proposal?

$ git checkout -b feature/solve p-eq-np
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME

                 YOU STILL IN THE SAME BRANCH ! ! ! !

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

***(but in bright RED)***


Another case!

$ git branch feature/solve p-eq-np
fatal: Not a valid object name: 'p-eq-np'.

I'll let that one to your imagination but please, make it appear in
red so we can easily (visually) realize that something went wrong.


This has been the third time in a month we accidentally pushed changes
to develop bc we didn't realize that the command failed.

Thanks!

Re: Please, paint new branch errors in RED (or any visible color)

[Ævar Arnfjörð Bjarmason]

On Fri, Dec 10 2021, Jose Wielandt wrote:

> Hi community,
>
> At my work we've been struggling a lot with not realizing that our new
> branch creation actually failed, ending up with a push directly to
> develop. What are those cases?
>
> $ git checkout -b feature/solve p-eq-np
> fatal: Cannot update paths and switch to branch 'feature/solve' at the
> same time.
>
> What's my proposal?
>
> $ git checkout -b feature/solve p-eq-np
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME
>
>                  YOU STILL IN THE SAME BRANCH ! ! ! !
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> ***(but in bright RED)***
>
>
> Another case!
>
> $ git branch feature/solve p-eq-np
> fatal: Not a valid object name: 'p-eq-np'.
>
> I'll let that one to your imagination but please, make it appear in
> red so we can easily (visually) realize that something went wrong.
>
>
> This has been the third time in a month we accidentally pushed changes
> to develop bc we didn't realize that the command failed.

I think if we'd improve the output we'd probably add some "advice"
output, i.e. "hint:" lines, not ALL CAPS.

But have you tried to see if the "git switch" command has the same UX
caveats? It was meant to address some of these tricky/unexpected issues
in 'checkout'.

Re: Please, paint new branch errors in RED (or any visible color)

[Fabian Stelzer]

On 10.12.2021 17:32, Ævar Arnfjörð Bjarmason wrote:
>
>On Fri, Dec 10 2021, Jose Wielandt wrote:
>
>> Hi community,
>>
>> At my work we've been struggling a lot with not realizing that our new
>> branch creation actually failed, ending up with a push directly to
>> develop. What are those cases?
>>
>> $ git checkout -b feature/solve p-eq-np
>> fatal: Cannot update paths and switch to branch 'feature/solve' at the
>> same time.
>>
>> What's my proposal?
>>
>> $ git checkout -b feature/solve p-eq-np
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME
>>
>>                  YOU STILL IN THE SAME BRANCH ! ! ! !
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> ***(but in bright RED)***
>>
>>
>> Another case!
>>
>> $ git branch feature/solve p-eq-np
>> fatal: Not a valid object name: 'p-eq-np'.
>>
>> I'll let that one to your imagination but please, make it appear in
>> red so we can easily (visually) realize that something went wrong.
>>
>>
>> This has been the third time in a month we accidentally pushed changes
>> to develop bc we didn't realize that the command failed.
>
>I think if we'd improve the output we'd probably add some "advice"
>output, i.e. "hint:" lines, not ALL CAPS.
>

Adding some color for die/error/warning() in general if we detect a tty 
might not a bad thing. I have encountered similar situations where an error 
gets lost in between `git log` output.

Re: Please, paint new branch errors in RED (or any visible color)

[Jose Wielandt]

Yes, I git switch has the same behavior.
I also agree that add hints could be a good idea.

2021-12-10 13:42 GMT-03:00, Fabian Stelzer <fs@gigacodes.de>:
> On 10.12.2021 17:32, Ævar Arnfjörð Bjarmason wrote:
>>
>>On Fri, Dec 10 2021, Jose Wielandt wrote:
>>
>>> Hi community,
>>>
>>> At my work we've been struggling a lot with not realizing that our new
>>> branch creation actually failed, ending up with a push directly to
>>> develop. What are those cases?
>>>
>>> $ git checkout -b feature/solve p-eq-np
>>> fatal: Cannot update paths and switch to branch 'feature/solve' at the
>>> same time.
>>>
>>> What's my proposal?
>>>
>>> $ git checkout -b feature/solve p-eq-np
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE
>>> SAME TIME
>>>
>>>                  YOU STILL IN THE SAME BRANCH ! ! ! !
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> ***(but in bright RED)***
>>>
>>>
>>> Another case!
>>>
>>> $ git branch feature/solve p-eq-np
>>> fatal: Not a valid object name: 'p-eq-np'.
>>>
>>> I'll let that one to your imagination but please, make it appear in
>>> red so we can easily (visually) realize that something went wrong.
>>>
>>>
>>> This has been the third time in a month we accidentally pushed changes
>>> to develop bc we didn't realize that the command failed.
>>
>>I think if we'd improve the output we'd probably add some "advice"
>>output, i.e. "hint:" lines, not ALL CAPS.
>>
>
> Adding some color for die/error/warning() in general if we detect a tty
> might not a bad thing. I have encountered similar situations where an error
>
> gets lost in between `git log` output.
>

Re: Please, paint new branch errors in RED (or any visible color)

[Ævar Arnfjörð Bjarmason]

On Fri, Dec 10 2021, Jose Wielandt wrote:

> Yes, I git switch has the same behavior.
> I also agree that add hints could be a good idea.

I'll pick up this topic.

I have some patches I'm trickling in to improve the general UX of these
fatal/error/warning/hint etc. messages, one part of that is trying to
get this RFC series in incrementally (some patches are already on-list:
https://lore.kernel.org/git/RFC-cover-00.21-00000000000-20211115T220831Z-avarab@gmail.com/

Adding color to the output would be relatively easy. I'll get to it, and
feel free to send me a reminder in some months (which is realistically
when you'd see it in a release) if you don't see it.

Thanks for the suggestion, & for caring about git's UX.

Re: Please, paint new branch errors in RED (or any visible color)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, Dec 10 2021, Jose Wielandt wrote:
>
>> Yes, I git switch has the same behavior.
>> I also agree that add hints could be a good idea.
>
> I'll pick up this topic.

Please make sure color challenged users can configure it away or
customize it somehow.

Making it opt-in is even better, but it is my personal taste.

Re: Please, paint new branch errors in RED (or any visible color)

[Ævar Arnfjörð Bjarmason]

On Sun, Dec 12 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Fri, Dec 10 2021, Jose Wielandt wrote:
>>
>>> Yes, I git switch has the same behavior.
>>> I also agree that add hints could be a good idea.
>>
>> I'll pick up this topic.
>
> Please make sure color challenged users can configure it away or
> customize it somehow.

Yes, I think it's a bug if we add any such coloring that isn't
configurable via the usual color.* configuration. Although in this case
it's usage.c. So perhaps "color.usage" (as in usage.c). But that squats
on any future hypothetical "git usage". So maybe "color.coreUsage" (a
"color.core.usage" would squat on any future "color.core.usage.<slot>"
(i.e. there's no 4-level keys)>

> Making it opt-in is even better, but it is my personal taste.

*nod*. I'll see how it turns out. FWIW I think that it's probably too
over-colored to do:

    <RED>fatal: the message</RED>

And it's probably better to just do:

    <RED>fatal</RED>: the message

But I'll see once we have actual examples. The advice output is
fully-colored now. I.e. "hint: message", not just the "hint" part...

Re: Please, paint new branch errors in RED (or any visible color)

[Eric Sunshine]

On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> Yes, I think it's a bug if we add any such coloring that isn't
> configurable via the usual color.* configuration. Although in this case
> it's usage.c. So perhaps "color.usage" (as in usage.c). But that squats
> on any future hypothetical "git usage". So maybe "color.coreUsage" (a
> "color.core.usage" would squat on any future "color.core.usage.<slot>"
> (i.e. there's no 4-level keys)>
>
> > Making it opt-in is even better, but it is my personal taste.
>
> *nod*. I'll see how it turns out. FWIW I think that it's probably too
> over-colored to do:
>
>     <RED>fatal: the message</RED>
>
> And it's probably better to just do:
>
>     <RED>fatal</RED>: the message
>
> But I'll see once we have actual examples. The advice output is
> fully-colored now. I.e. "hint: message", not just the "hint" part...

As a minor bikeshedding datapoint, a script I wrote a few years ago
highlights outdated entries in a larger output. The highlighting is
applied only to a single word ("outdated") on one line related to the
item, and I found that my eye would regularly glide right over the
highlighting in the somewhat voluminous output without ever seeing the
highlight. Very recently, I changed it to highlight the entire line,
and that has helped me take more notice of it (though, admittedly, I
still sometimes still overlook the highlighted item).