threads / discuss / 57064

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

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

## tl;dr

8 messages between Dec 10, 2021 and Dec 12, 2021.

replies: 7people: 5as markdown or json

Jose Wielandt· Dec 10, 2021, 11:36 UTC · lore
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!
Ævar Arnfjörð Bjarmason· Dec 10, 2021, 16:32 UTC · re: Jose Wielandt · lore

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

On Fri, Dec 10 2021, Jose Wielandt wrote:
Show 35 quoted lines
> 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'.

Fabian Stelzer· Dec 10, 2021, 16:42 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

On 10.12.2021 17:32, Ævar Arnfjörð Bjarmason wrote:
Show 42 quoted lines
>
>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.

Jose Wielandt· Dec 10, 2021, 19:09 UTC · re: Fabian Stelzer · lore

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

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>:
Show 50 quoted lines
> 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.
>
Ævar Arnfjörð Bjarmason· Dec 11, 2021, 02:30 UTC · re: Jose Wielandt · lore

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

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.
Junio C Hamano· Dec 12, 2021, 18:38 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 6 quoted lines
> 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.
Ævar Arnfjörð Bjarmason· Dec 12, 2021, 19:01 UTC · re: Junio C Hamano · lore

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

On Sun, Dec 12 2021, Junio C Hamano wrote:
Show 11 quoted lines
> Æ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...

Eric Sunshine· Dec 12, 2021, 22:27 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 20 quoted lines
> 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).

← back to recent threads