{"thread":{"id":"64431","subject":"","startedAt":"2025-11-04T09:22:05Z","lastAt":"2025-11-06T08:09:44Z","messageCount":6,"participants":["Michael Roach","Kristoffer Haugsbakk","Lucas Seiki Oshiro"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"530183","messageId":"0be81c5272a5e42c8471239a1369ee6c32401bb1@mroach.com","threadId":"64431","inReplyTo":null,"subject":"","fromName":"Michael Roach","fromEmail":"mroach@mroach.com","sentAt":"2025-11-04T09:22:00Z","receivedAt":"2025-11-04T09:22:05Z","isPatch":false,"sender":{"key":"mroach@mroach.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nI ran:\n  $ git grep -rl --color=never '#!/.*/env ruby'\n\nWhat did you expect to happen? (Expected behavior)\n\nGet a list of filenames where the contents matched the regex\n\nWhat happened instead? (Actual behavior)\n\nFor one of my files named `ensure-string-env.rb` was printed with part of the path in colour,\nand the first dash of the filename replaced with a colon.\n\nWhat's different between what you expected and what actually happened?\n\nI expected:\n  images/deploy_tools/scripts/ensure-string-env.rb\n\nI got:\n  images/deploy_tools/scripts/ensure:string-env.rb\n\n  The string up to the colon was printed in pink\n\nAnything else you want to add:\n\nI tested with both zsh and bash with the same result.\nI teested with git 2.47.3 and 2.49.1 everything worked correctly.\nI also tried other terminals to rule that out.\n\n2.51.1 is the current version on Fedora 42\n\nI was able to reproduce this with:\n  $ echo foo > test-one\n  $ git add test-one\n  $ git grep -l foo\n  test:one\n\nThis seems to be reproducible with any filename containing a dash\n\n[System Info]\ngit version:\ngit version 2.51.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.11.1\nOpenSSL: OpenSSL 3.2.6 30 Sep 2025\nzlib-ng: 2.2.5\nSHA-1: SHA1_DC\nSHA-256: SHA256_BLK\ndefault-ref-format: files\ndefault-hash: sha1\nuname: Linux 6.17.5-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 24 14:10:01 UTC 2025 x86_64\ncompiler info: gnuc: 15.2\nlibc info: glibc: 2.41\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\npre-commit\n"},{"id":"530186","messageId":"ed8a6d59-9b85-4ca6-a23a-1e43efaa7efa@app.fastmail.com","threadId":"64431","inReplyTo":"0be81c5272a5e42c8471239a1369ee6c32401bb1@mroach.com","subject":"Re:","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-04T10:24:33Z","receivedAt":"2025-11-04T10:25:22Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, Nov 4, 2025, at 10:22, Michael Roach wrote:\n>[snip]\n> For one of my files named `ensure-string-env.rb` was printed with part\n> of the path in colour,\n> and the first dash of the filename replaced with a colon.\n\nI have seen something similar when using the Delta pager. I’m pretty\nsure that it replaced a hyphen with a colon.\n\nhttps://github.com/dandavison/delta\n\nI don’t think I’ve seen this behavior with `git --no-pager`.\n\nDon’t know about the coloring part (despite `--color=never`).\n\n>[snip]\n"},{"id":"530251","messageId":"F8EAD922-315A-42F8-8E77-5C562B5041ED@gmail.com","threadId":"64431","inReplyTo":"ed8a6d59-9b85-4ca6-a23a-1e43efaa7efa@app.fastmail.com","subject":"Re:","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-11-05T14:55:54Z","receivedAt":"2025-11-05T14:56:08Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> I have seen something similar when using the Delta pager. I’m pretty\n> sure that it replaced a hyphen with a colon.\n\nIt's a known bug in Delta:\n\nhttps://github.com/dandavison/delta/issues/1259\n\n> I don’t think I’ve seen this behavior with `git --no-pager`.\n\nI think it is a good idea to also see what happens when using another\npager, for example, less (`git -c core.pager=less ...`) or cat\n(`git -c core.pager=cat ...`).\n\nMichael, can you run with those three mentioned options and see what\nhappens? Last year I spent some hours trying to find the cause of the\nsame bug in Git but then I found out that it was actually a bug in\nDelta."},{"id":"530252","messageId":"9f8acce4-1a4c-4f4f-b8f1-827d778fe6e3@app.fastmail.com","threadId":"64431","inReplyTo":"F8EAD922-315A-42F8-8E77-5C562B5041ED@gmail.com","subject":"Re:","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-05T15:01:04Z","receivedAt":"2025-11-05T15:01:39Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Wed, Nov 5, 2025, at 15:55, Lucas Seiki Oshiro wrote:\n>> I have seen something similar when using the Delta pager. I’m pretty\n>> sure that it replaced a hyphen with a colon.\n>\n> It's a known bug in Delta:\n>\n> https://github.com/dandavison/delta/issues/1259\n>\n>> I don’t think I’ve seen this behavior with `git --no-pager`.\n>\n> I think it is a good idea to also see what happens when using another\n> pager, for example, less (`git -c core.pager=less ...`) or cat\n> (`git -c core.pager=cat ...`).\n>\n> Michael, can you run with those three mentioned options and see what\n> happens? Last year I spent some hours trying to find the cause of the\n> same bug in Git but then I found out that it was actually a bug in\n> Delta.\n\nSorry, I didn’t see that he only replied to me previously:\n\nOn Tue, Nov 4, 2025, at 12:15, Michael Roach wrote:\n> Just when I thought I had considered all the factors before reporting \n> this, you got it.\n> I am using Delta as my pager. My tests with other git versions were via \n> Docker, so there was no pager.\n>\n> I confirmed that using `git --no-pager grep` doesn't have this issue.\n>\n> Sorry for the bug report noise and thanks for figuring that out.\n"},{"id":"530284","messageId":"FE487800-06D5-46ED-9C78-3C42EC62EB4E@gmail.com","threadId":"64431","inReplyTo":"9f8acce4-1a4c-4f4f-b8f1-827d778fe6e3@app.fastmail.com","subject":"Re:","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-11-06T00:05:54Z","receivedAt":"2025-11-06T00:06:09Z","isPatch":false,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> Sorry, I didn’t see that he only replied to me previously:\n\nThanks for forwarding that!"},{"id":"530293","messageId":"616fa0e461f2bf15bd3588914091fd9214183a8c@mroach.com","threadId":"64431","inReplyTo":"FE487800-06D5-46ED-9C78-3C42EC62EB4E@gmail.com","subject":"Re:","fromName":"Michael Roach","fromEmail":"mroach@mroach.com","sentAt":"2025-11-06T08:09:40Z","receivedAt":"2025-11-06T08:09:44Z","isPatch":false,"sender":{"key":"mroach@mroach.com","avatar":null},"body":"Sorry I didn't do a reply to all on Kristoffer's response. Can you tell it's my first time here? \nThank you both for your time on this!\n\n\n\nNovember 6, 2025 at 01:05, \"Lucas Seiki Oshiro\" <lucasseikioshiro@gmail.com mailto:lucasseikioshiro@gmail.com?to=%22Lucas%20Seiki%20Oshiro%22%20%3Clucasseikioshiro%40gmail.com%3E > wrote:\n\n\n> \n> > \n> > Sorry, I didn’t see that he only replied to me previously:\n> > \n> Thanks for forwarding that!\n>\n"}]}