{"thread":{"id":"57064","subject":"Please, paint new branch errors in RED (or any visible color)","startedAt":"2021-12-10T11:36:41Z","lastAt":"2021-12-12T22:27:37Z","messageCount":8,"participants":["Jose Wielandt","Ævar Arnfjörð Bjarmason","Fabian Stelzer","Junio C Hamano","Eric Sunshine"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"443790","messageId":"CAJrA3nLUG_m1ftdAyzFBkmL3m1vMPuv5dd3bYVVOmXV-fThwnA@mail.gmail.com","threadId":"57064","inReplyTo":null,"subject":"Please, paint new branch errors in RED (or any visible color)","fromName":"Jose Wielandt","fromEmail":"jose.wielandt@timining.com","sentAt":"2021-12-10T11:36:37Z","receivedAt":"2021-12-10T11:36:41Z","isPatch":false,"sender":{"key":"jose.wielandt@timining.com","avatar":null},"body":"Hi community,\n\nAt my work we've been struggling a lot with not realizing that our new\nbranch creation actually failed, ending up with a push directly to\ndevelop. What are those cases?\n\n$ git checkout -b feature/solve p-eq-np\nfatal: Cannot update paths and switch to branch 'feature/solve' at the\nsame time.\n\nWhat's my proposal?\n\n$ git checkout -b feature/solve p-eq-np\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n\nFATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME\n\n YOU STILL IN THE SAME BRANCH ! ! ! !\n\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n\n***(but in bright RED)***\n\n\nAnother case!\n\n$ git branch feature/solve p-eq-np\nfatal: Not a valid object name: 'p-eq-np'.\n\nI'll let that one to your imagination but please, make it appear in\nred so we can easily (visually) realize that something went wrong.\n\n\nThis has been the third time in a month we accidentally pushed changes\nto develop bc we didn't realize that the command failed.\n\nThanks!\n"},{"id":"443824","messageId":"211210.86r1akbes8.gmgdl@evledraar.gmail.com","threadId":"57064","inReplyTo":"CAJrA3nLUG_m1ftdAyzFBkmL3m1vMPuv5dd3bYVVOmXV-fThwnA@mail.gmail.com","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-10T16:32:41Z","receivedAt":"2021-12-10T16:33:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 10 2021, Jose Wielandt wrote:\n\n> Hi community,\n>\n> At my work we've been struggling a lot with not realizing that our new\n> branch creation actually failed, ending up with a push directly to\n> develop. What are those cases?\n>\n> $ git checkout -b feature/solve p-eq-np\n> fatal: Cannot update paths and switch to branch 'feature/solve' at the\n> same time.\n>\n> What's my proposal?\n>\n> $ git checkout -b feature/solve p-eq-np\n> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>\n> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME\n>\n> YOU STILL IN THE SAME BRANCH ! ! ! !\n>\n> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>\n> ***(but in bright RED)***\n>\n>\n> Another case!\n>\n> $ git branch feature/solve p-eq-np\n> fatal: Not a valid object name: 'p-eq-np'.\n>\n> I'll let that one to your imagination but please, make it appear in\n> red so we can easily (visually) realize that something went wrong.\n>\n>\n> This has been the third time in a month we accidentally pushed changes\n> to develop bc we didn't realize that the command failed.\n\nI think if we'd improve the output we'd probably add some \"advice\"\noutput, i.e. \"hint:\" lines, not ALL CAPS.\n\nBut have you tried to see if the \"git switch\" command has the same UX\ncaveats? It was meant to address some of these tricky/unexpected issues\nin 'checkout'.\n"},{"id":"443825","messageId":"20211210164249.bahhe5ogjjhz4lxo@fs","threadId":"57064","inReplyTo":"211210.86r1akbes8.gmgdl@evledraar.gmail.com","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-10T16:42:49Z","receivedAt":"2021-12-10T16:42:53Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 10.12.2021 17:32, Ævar Arnfjörð Bjarmason wrote:\n>\n>On Fri, Dec 10 2021, Jose Wielandt wrote:\n>\n>> Hi community,\n>>\n>> At my work we've been struggling a lot with not realizing that our new\n>> branch creation actually failed, ending up with a push directly to\n>> develop. What are those cases?\n>>\n>> $ git checkout -b feature/solve p-eq-np\n>> fatal: Cannot update paths and switch to branch 'feature/solve' at the\n>> same time.\n>>\n>> What's my proposal?\n>>\n>> $ git checkout -b feature/solve p-eq-np\n>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>>\n>> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE SAME TIME\n>>\n>> YOU STILL IN THE SAME BRANCH ! ! ! !\n>>\n>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>>\n>> ***(but in bright RED)***\n>>\n>>\n>> Another case!\n>>\n>> $ git branch feature/solve p-eq-np\n>> fatal: Not a valid object name: 'p-eq-np'.\n>>\n>> I'll let that one to your imagination but please, make it appear in\n>> red so we can easily (visually) realize that something went wrong.\n>>\n>>\n>> This has been the third time in a month we accidentally pushed changes\n>> to develop bc we didn't realize that the command failed.\n>\n>I think if we'd improve the output we'd probably add some \"advice\"\n>output, i.e. \"hint:\" lines, not ALL CAPS.\n>\n\nAdding some color for die/error/warning() in general if we detect a tty \nmight not a bad thing. I have encountered similar situations where an error \ngets lost in between `git log` output.\n"},{"id":"443832","messageId":"CAJrA3nKbUK=_5d5KTCDehrfge4y1aB9YGsFwQYNzUDWGcfog4w@mail.gmail.com","threadId":"57064","inReplyTo":"20211210164249.bahhe5ogjjhz4lxo@fs","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Jose Wielandt","fromEmail":"jose.wielandt@timining.com","sentAt":"2021-12-10T19:09:32Z","receivedAt":"2021-12-10T19:09:35Z","isPatch":false,"sender":{"key":"jose.wielandt@timining.com","avatar":null},"body":"Yes, I git switch has the same behavior.\nI also agree that add hints could be a good idea.\n\n2021-12-10 13:42 GMT-03:00, Fabian Stelzer :\n> On 10.12.2021 17:32, Ævar Arnfjörð Bjarmason wrote:\n>>\n>>On Fri, Dec 10 2021, Jose Wielandt wrote:\n>>\n>>> Hi community,\n>>>\n>>> At my work we've been struggling a lot with not realizing that our new\n>>> branch creation actually failed, ending up with a push directly to\n>>> develop. What are those cases?\n>>>\n>>> $ git checkout -b feature/solve p-eq-np\n>>> fatal: Cannot update paths and switch to branch 'feature/solve' at the\n>>> same time.\n>>>\n>>> What's my proposal?\n>>>\n>>> $ git checkout -b feature/solve p-eq-np\n>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>>>\n>>> FATAL: CANNOT UPDATE PATHS AND SWITCH TO BRANCH 'feature/solve' AT THE\n>>> SAME TIME\n>>>\n>>> YOU STILL IN THE SAME BRANCH ! ! ! !\n>>>\n>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n>>>\n>>> ***(but in bright RED)***\n>>>\n>>>\n>>> Another case!\n>>>\n>>> $ git branch feature/solve p-eq-np\n>>> fatal: Not a valid object name: 'p-eq-np'.\n>>>\n>>> I'll let that one to your imagination but please, make it appear in\n>>> red so we can easily (visually) realize that something went wrong.\n>>>\n>>>\n>>> This has been the third time in a month we accidentally pushed changes\n>>> to develop bc we didn't realize that the command failed.\n>>\n>>I think if we'd improve the output we'd probably add some \"advice\"\n>>output, i.e. \"hint:\" lines, not ALL CAPS.\n>>\n>\n> Adding some color for die/error/warning() in general if we detect a tty\n> might not a bad thing. I have encountered similar situations where an error\n>\n> gets lost in between `git log` output.\n>\n"},{"id":"443860","messageId":"211211.86a6h7c1mq.gmgdl@evledraar.gmail.com","threadId":"57064","inReplyTo":"CAJrA3nKbUK=_5d5KTCDehrfge4y1aB9YGsFwQYNzUDWGcfog4w@mail.gmail.com","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-11T02:30:00Z","receivedAt":"2021-12-11T02:32:33Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 10 2021, Jose Wielandt wrote:\n\n> Yes, I git switch has the same behavior.\n> I also agree that add hints could be a good idea.\n\nI'll pick up this topic.\n\nI have some patches I'm trickling in to improve the general UX of these\nfatal/error/warning/hint etc. messages, one part of that is trying to\nget this RFC series in incrementally (some patches are already on-list:\nhttps://lore.kernel.org/git/RFC-cover-00.21-00000000000-20211115T220831Z-avarab@gmail.com/\n\nAdding color to the output would be relatively easy. I'll get to it, and\nfeel free to send me a reminder in some months (which is realistically\nwhen you'd see it in a release) if you don't see it.\n\nThanks for the suggestion, & for caring about git's UX.\n"},{"id":"443904","messageId":"xmqq4k7dlld3.fsf@gitster.g","threadId":"57064","inReplyTo":"211211.86a6h7c1mq.gmgdl@evledraar.gmail.com","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-12T18:38:16Z","receivedAt":"2021-12-12T18:38:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Fri, Dec 10 2021, Jose Wielandt wrote:\n>\n>> Yes, I git switch has the same behavior.\n>> I also agree that add hints could be a good idea.\n>\n> I'll pick up this topic.\n\nPlease make sure color challenged users can configure it away or\ncustomize it somehow.\n\nMaking it opt-in is even better, but it is my personal taste.\n"},{"id":"443907","messageId":"211212.86o85labj1.gmgdl@evledraar.gmail.com","threadId":"57064","inReplyTo":"xmqq4k7dlld3.fsf@gitster.g","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-12T19:01:34Z","receivedAt":"2021-12-12T19:06:15Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Dec 12 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Fri, Dec 10 2021, Jose Wielandt wrote:\n>>\n>>> Yes, I git switch has the same behavior.\n>>> I also agree that add hints could be a good idea.\n>>\n>> I'll pick up this topic.\n>\n> Please make sure color challenged users can configure it away or\n> customize it somehow.\n\nYes, I think it's a bug if we add any such coloring that isn't\nconfigurable via the usual color.* configuration. Although in this case\nit's usage.c. So perhaps \"color.usage\" (as in usage.c). But that squats\non any future hypothetical \"git usage\". So maybe \"color.coreUsage\" (a\n\"color.core.usage\" would squat on any future \"color.core.usage.\"\n(i.e. there's no 4-level keys)>\n\n> Making it opt-in is even better, but it is my personal taste.\n\n*nod*. I'll see how it turns out. FWIW I think that it's probably too\nover-colored to do:\n\n fatal: the message\n\nAnd it's probably better to just do:\n\n fatal: the message\n\nBut I'll see once we have actual examples. The advice output is\nfully-colored now. I.e. \"hint: message\", not just the \"hint\" part...\n"},{"id":"443934","messageId":"CAPig+cT-9GAtadPW-=3sVFVWyKTf9Kybs3TwSW-s0BzhsfGJyQ@mail.gmail.com","threadId":"57064","inReplyTo":"211212.86o85labj1.gmgdl@evledraar.gmail.com","subject":"Re: Please, paint new branch errors in RED (or any visible color)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-12-12T22:27:24Z","receivedAt":"2021-12-12T22:27:37Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason\n wrote:\n> Yes, I think it's a bug if we add any such coloring that isn't\n> configurable via the usual color.* configuration. Although in this case\n> it's usage.c. So perhaps \"color.usage\" (as in usage.c). But that squats\n> on any future hypothetical \"git usage\". So maybe \"color.coreUsage\" (a\n> \"color.core.usage\" would squat on any future \"color.core.usage.\"\n> (i.e. there's no 4-level keys)>\n>\n> > Making it opt-in is even better, but it is my personal taste.\n>\n> *nod*. I'll see how it turns out. FWIW I think that it's probably too\n> over-colored to do:\n>\n> fatal: the message\n>\n> And it's probably better to just do:\n>\n> fatal: the message\n>\n> But I'll see once we have actual examples. The advice output is\n> fully-colored now. I.e. \"hint: message\", not just the \"hint\" part...\n\nAs a minor bikeshedding datapoint, a script I wrote a few years ago\nhighlights outdated entries in a larger output. The highlighting is\napplied only to a single word (\"outdated\") on one line related to the\nitem, and I found that my eye would regularly glide right over the\nhighlighting in the somewhat voluminous output without ever seeing the\nhighlight. Very recently, I changed it to highlight the entire line,\nand that has helped me take more notice of it (though, admittedly, I\nstill sometimes still overlook the highlighted item).\n"}]}