Am 27.07.22 um 22:21 schrieb CH: > Somehow when copying and pasting a commit from a website to the command > line, a UTF-8 Byte Order Mark (BOM) > [https://en.wikipedia.org/wiki/Byte_order_mark] was appended to one of > the commit ids. BOMs are invisible, as are many other UTF-8 code > points. The upshot was that Git didn't like it, and complained bitterly: > >> $ strace -etrace=execve -s 200 git diff >> 038179704f0066aa815d5429221cf381ff4ef289 >> 47346a462d8ba40b9a8b073e351c362522c46aa6 >> >> execve("/usr/bin/git", ["git", "diff", >> "038179704f0066aa815d5429221cf381ff4ef289\357\273\277", >> "47346a462d8ba40b9a8b073e351c362522c46aa6"], 0x7fffec3c4bb0 /* 80 vars >> */) = 0 >> >> fatal: ambiguous argument '038179704f0066aa815d5429221cf381ff4ef289': >> unknown revision or path not in the working tree. >> Use '--' to separate paths from revisions, like this: >> 'git <command> [<revision>...] -- [<file>...]' >> +++ exited with 128 +++ > > Feature request: > ================ > > When printing the "fatal: ambiguous argument '......': ....", perhaps > escape (url or otherwise) the ambiguous argument when printing it in the > error message, or maybe add a sentence about non-ASCII characters being > found. That's not going to fly, IMHO, because when I type git diff todo/René I would not want to see fatal: ambiguous argument 'todo/Ren\303\251': unknown ... I'm convinced that there are thousands of users who use non-ASCII branch and file names that they also frequently mis-type. They'd all be greeted with unintelligible nerdy gibberish. I may be able to change my mind if ambiguous input (in the sense of "is not what it seems to be") leads to a security hazard that is unique to Git. -- Hannes
