# Please, paint new branch errors in RED (or any visible color) 8 messages from 2021-12-10 to 2021-12-12. Participants: Jose Wielandt, Ævar Arnfjörð Bjarmason, Fabian Stelzer, Junio C Hamano, Eric Sunshine. Thread: https://gitlist.dev/t/57064 ## Jose Wielandt, 2021-12-10 11:36 Subject: Please, paint new branch errors in RED (or any visible color) Message-ID: URL: https://gitlist.dev/e/CAJrA3nLUG_m1ftdAyzFBkmL3m1vMPuv5dd3bYVVOmXV-fThwnA%40mail.gmail.com ``` 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, 2021-12-10 16:32 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: <211210.86r1akbes8.gmgdl@evledraar.gmail.com> URL: https://gitlist.dev/e/211210.86r1akbes8.gmgdl%40evledraar.gmail.com In-Reply-To: ``` 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'. ``` ## Fabian Stelzer, 2021-12-10 16:42 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: <20211210164249.bahhe5ogjjhz4lxo@fs> URL: https://gitlist.dev/e/20211210164249.bahhe5ogjjhz4lxo%40fs In-Reply-To: <211210.86r1akbes8.gmgdl@evledraar.gmail.com> ``` 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. ``` ## Jose Wielandt, 2021-12-10 19:09 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: URL: https://gitlist.dev/e/CAJrA3nKbUK%3D_5d5KTCDehrfge4y1aB9YGsFwQYNzUDWGcfog4w%40mail.gmail.com In-Reply-To: <20211210164249.bahhe5ogjjhz4lxo@fs> ``` 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 : > 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, 2021-12-11 02:30 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: <211211.86a6h7c1mq.gmgdl@evledraar.gmail.com> URL: https://gitlist.dev/e/211211.86a6h7c1mq.gmgdl%40evledraar.gmail.com In-Reply-To: ``` 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, 2021-12-12 18:38 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: URL: https://gitlist.dev/e/xmqq4k7dlld3.fsf%40gitster.g In-Reply-To: <211211.86a6h7c1mq.gmgdl@evledraar.gmail.com> ``` Ævar Arnfjörð Bjarmason 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. ``` ## Ævar Arnfjörð Bjarmason, 2021-12-12 19:01 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: <211212.86o85labj1.gmgdl@evledraar.gmail.com> URL: https://gitlist.dev/e/211212.86o85labj1.gmgdl%40evledraar.gmail.com In-Reply-To: ``` On Sun, Dec 12 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason 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." (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: fatal: the message And it's probably better to just do: fatal: 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, 2021-12-12 22:27 Subject: Re: Please, paint new branch errors in RED (or any visible color) Message-ID: URL: https://gitlist.dev/e/CAPig%2BcT-9GAtadPW-%3D3sVFVWyKTf9Kybs3TwSW-s0BzhsfGJyQ%40mail.gmail.com In-Reply-To: <211212.86o85labj1.gmgdl@evledraar.gmail.com> ``` On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason 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." > (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: > > fatal: the message > > And it's probably better to just do: > > fatal: 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). ```