{"thread":{"id":"59590","subject":"Git branch capitalisation bug?","startedAt":"2023-04-13T10:35:50Z","lastAt":"2023-04-20T07:29:20Z","messageCount":5,"participants":["Ilya Kamenshchikov","Torsten Bögershausen","Junio C Hamano","Chris Torek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"475273","messageId":"CAAp-DqK=CPxpH0ZhA=k8GRFvSz3odoOLhOgAqfYSBpz28JK+hg@mail.gmail.com","threadId":"59590","inReplyTo":null,"subject":"Git branch capitalisation bug?","fromName":"Ilya Kamenshchikov","fromEmail":"ikamenshchikov@gmail.com","sentAt":"2023-04-13T10:35:36Z","receivedAt":"2023-04-13T10:35:50Z","isPatch":false,"sender":{"key":"ikamenshchikov@gmail.com","avatar":null},"body":"What did you do before the bug happened? (Steps to reproduce your issue)\nCreated a branch \"feature/macos_tests\", pushed to remote as\n\"origin/feature/macos_tests\".\n\nWhat did you expect to happen? (Expected behavior)\nremote branch \"feature/macos_tests\" to be created.\n\nWhat happened instead? (Actual behavior)\nremote branch name is \"Feature/macos_tests\" (capitalised). This\ndoesn't play nicely with not case sensitive macos FS.\n\n\n\n[System Info]\ngit version:\ngit version 2.40.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01\nPST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64 x86_64\ncompiler info: clang: 14.0.0 (clang-1400.0.29.202)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /usr/local/bin/fish\n\n\n[Enabled Hooks]\npre-push\n(remark: reproduced also when uninstalling this hook)\n\nRaw output:\n\n~ $ cd bosch/rlcore                                       (base) 12:11:42\n~/b/rlcore (feature/macos_tests|✚2) $ git push            (base) 12:11:49\nfatal: The current branch feature/macos_tests has no upstream branch.\nTo push the current branch and set the remote as upstream, use\n\n    git push --set-upstream origin feature/macos_tests\n\nTo have this happen automatically for branches without a tracking\nupstream, see 'push.autoSetupRemote' in 'git help config'.\n\n~/b/rlcore (feature/macos_tests|✚2) [128] $ git push --set-upstream\norigin feature/macos_tests\nTotal 0 (delta 0), reused 0 (delta 0), pack-reused 0\nThank you for filling out a Git bug report!\nremote:\nremote: Create a pull request for 'feature/macos_tests' on GitHub by visiting:\nremote:      https://github.boschdevcloud.com/CR/rlcore/pull/new/feature/macos_tests\nremote:\nTo https://github.boschdevcloud.com/CR/rlcore.git\n * [new branch]        feature/macos_tests -> feature/macos_tests\nbranch 'feature/macos_tests' set up to track 'origin/feature/macos_tests'.\n~/b/rlcore (feature/macos_tests|✚2) $ gl                  (base) 12:16:10\nc001bc75 2023-04-13 | commit message (#514) (HEAD ->\nfeature/macos_tests, origin/main, origin/git_problems, origin/HEAD,\norigin/Feature/macos_tests) [Rich..]\n\nBest Regards,\n--\nIlya Kamen\n"},{"id":"475314","messageId":"20230413190302.drmmdrkv7vfps3qg@tb-raspi4","threadId":"59590","inReplyTo":"CAAp-DqK=CPxpH0ZhA=k8GRFvSz3odoOLhOgAqfYSBpz28JK+hg@mail.gmail.com","subject":"Re: Git branch capitalisation bug?","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-04-13T19:03:02Z","receivedAt":"2023-04-13T19:03:09Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Apr 13, 2023 at 12:35:36PM +0200, Ilya Kamenshchikov wrote:\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> Created a branch \"feature/macos_tests\", pushed to remote as\n> \"origin/feature/macos_tests\".\n>\n> What did you expect to happen? (Expected behavior)\n> remote branch \"feature/macos_tests\" to be created.\n>\n> What happened instead? (Actual behavior)\n> remote branch name is \"Feature/macos_tests\" (capitalised). This\n> doesn't play nicely with not case sensitive macos FS.\n>\n>\n>\n> [System Info]\n> git version:\n> git version 2.40.0\n> cpu: x86_64\n> no commit associated with this build\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n> uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01\n> PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64 x86_64\n> compiler info: clang: 14.0.0 (clang-1400.0.29.202)\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): /usr/local/bin/fish\n>\n>\n> [Enabled Hooks]\n> pre-push\n> (remark: reproduced also when uninstalling this hook)\n>\n> Raw output:\n>\n> ~ $ cd bosch/rlcore                                       (base) 12:11:42\n> ~/b/rlcore (feature/macos_tests|✚2) $ git push            (base) 12:11:49\n> fatal: The current branch feature/macos_tests has no upstream branch.\n> To push the current branch and set the remote as upstream, use\n>\n>     git push --set-upstream origin feature/macos_tests\n>\n> To have this happen automatically for branches without a tracking\n> upstream, see 'push.autoSetupRemote' in 'git help config'.\n>\n> ~/b/rlcore (feature/macos_tests|✚2) [128] $ git push --set-upstream\n> origin feature/macos_tests\n> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0\n> Thank you for filling out a Git bug report!\n> remote:\n> remote: Create a pull request for 'feature/macos_tests' on GitHub by visiting:\n> remote:      https://github.boschdevcloud.com/CR/rlcore/pull/new/feature/macos_tests\n> remote:\n> To https://github.boschdevcloud.com/CR/rlcore.git\n>  * [new branch]        feature/macos_tests -> feature/macos_tests\n> branch 'feature/macos_tests' set up to track 'origin/feature/macos_tests'.\n> ~/b/rlcore (feature/macos_tests|✚2) $ gl                  (base) 12:16:10\n> c001bc75 2023-04-13 | commit message (#514) (HEAD ->\n> feature/macos_tests, origin/main, origin/git_problems, origin/HEAD,\n> origin/Feature/macos_tests) [Rich..]\n>\n> Best Regards,\n> --\n> Ilya Kamen\n\nI am not sure, where this Capitalizations comes from.\nI don't have an account on boschdevcloud.com to test.\nIs it possible to reproduce it with a public repo ?\nOtherwise, should we suspect boschdevcloud.com for it ?\n\nAny other thoughts from anybody ?\n"},{"id":"475315","messageId":"xmqqfs93y166.fsf@gitster.g","threadId":"59590","inReplyTo":"20230413190302.drmmdrkv7vfps3qg@tb-raspi4","subject":"Re: Git branch capitalisation bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-04-13T20:31:13Z","receivedAt":"2023-04-13T20:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> I am not sure, where this Capitalizations comes from.\n> I don't have an account on boschdevcloud.com to test.\n> Is it possible to reproduce it with a public repo ?\n> Otherwise, should we suspect boschdevcloud.com for it ?\n>\n> Any other thoughts from anybody ?\n\nIn the transcript I do not see any \"git pull\" done from the other\nside, so the \"origin/Feature/macos_tests\" in the commit decoration\nthat can be seen in the last part of the transcript may have been\ncreated locally.  Output from\n\n $ git ls-remote origin | grep macos_tests\n\nmight be a way to see which end of the connection has the issue.\n\n"},{"id":"475727","messageId":"CAAp-DqKzutP2JQB25kzyMG56=sqArpqZ0341-ayaV48pca4skA@mail.gmail.com","threadId":"59590","inReplyTo":"xmqqfs93y166.fsf@gitster.g","subject":"Re: Git branch capitalisation bug?","fromName":"Ilya Kamenshchikov","fromEmail":"ikamenshchikov@gmail.com","sentAt":"2023-04-20T07:04:09Z","receivedAt":"2023-04-20T07:04:25Z","isPatch":false,"sender":{"key":"ikamenshchikov@gmail.com","avatar":null},"body":"I've recollected the history of how this issue occurred more and did\nfew more tests. I'm now working with branch named \"feature/git_repro\":\n1) The error first occurred when I worked with a colleague on a same\nbranch, and he really used capital \"Feature/branch\".\n2) today, after initial push and doing git log, local git believes it\nto be \"Feature/repro_git\", while `ls-remote` says it's\n\"feature/repro_git\"\n```\n$ git checkout -b feature/repro_git\n$ git push --set-upstream origin feature/repro_git\n$ git log\ncommit 846df8e6d2f921d0ee2e7c427ca174fae291b040 (HEAD ->\nfeature/repro_git, origin/Feature/repro_git)\n$ git ls-remote origin | grep repro\n                      (base) 08:44:31\n846df8e6d2f921d0ee2e7c427ca174fae291b040 refs/heads/feature/repro_git\n```\n3) So I conclude there must be some local information saying branch\nhas Capitalised name, while on remote all is normal.\n$ ls .git/refs/remotes/origin\nFeature/\n# note: doesn't contain \"feature/\"\n---\nMy wild speculation now: when I first checked out the branch\nFeature/branch of my colleague, git has rewritten\n.git/refs/remotes/origin/feature as capitalised Feature.\n---\nI will try to reproduce this on public GitHub later.\n\nBest Regards,\n--\nIlya Kamen\n\nOn Thu, Apr 13, 2023 at 10:34 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Torsten Bögershausen <tboegi@web.de> writes:\n>\n> > I am not sure, where this Capitalizations comes from.\n> > I don't have an account on boschdevcloud.com to test.\n> > Is it possible to reproduce it with a public repo ?\n> > Otherwise, should we suspect boschdevcloud.com for it ?\n> >\n> > Any other thoughts from anybody ?\n>\n> In the transcript I do not see any \"git pull\" done from the other\n> side, so the \"origin/Feature/macos_tests\" in the commit decoration\n> that can be seen in the last part of the transcript may have been\n> created locally.  Output from\n>\n>  $ git ls-remote origin | grep macos_tests\n>\n> might be a way to see which end of the connection has the issue.\n>\n"},{"id":"475729","messageId":"CAPx1GvdsH-wO64sE3k5M_KAJy+x2o=LvGHLY+-sqksD7bJ2NKg@mail.gmail.com","threadId":"59590","inReplyTo":"CAAp-DqKzutP2JQB25kzyMG56=sqArpqZ0341-ayaV48pca4skA@mail.gmail.com","subject":"Re: Git branch capitalisation bug?","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2023-04-20T07:28:41Z","receivedAt":"2023-04-20T07:29:20Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Thu, Apr 20, 2023 at 12:08 AM Ilya Kamenshchikov\n<ikamenshchikov@gmail.com> wrote:\n> I've recollected the history of how this issue occurred more and did\n> few more tests. I'm now working with branch named \"feature/git_repro\":\n> 1) The error first occurred when I worked with a colleague on a same\n> branch, and he really used capital \"Feature/branch\".\n\nThe bug -- or \"feature\", depending on how you believe this all\n*should* work -- is simple in concept and difficult in\nreproduction because there are multiple moving parts.\n\nHere's the concept:\n\n * In Git, branch names are always case sensitive.\n\n * But Git *sometimes* relies on the *OS* / file-system to\n   implement this.\n\n * Some OSes / file-systems are case *in*sensitive.\n\nWhen Git uses a case-INsensitive file-system to store a case-\nsensitive branch name component, the OS / file-system loses the\ncase distinction. Exactly how that happens is up to the OS /\nfile-system, but we can see how common macOS and Windows systems\ndo it.\n\nOn these systems, when creating a file or directory, the *first*\ncreation attempt \"wins\". That is, if any command or process\ngoes to create a file or directory named \"Feature\", and no such\nfile or directory exists *now*, the file or directory is created\nwith precisely this set of casing. But if the file or directory\n*already exists* in any casing (upper and/or lower), the system\nuses the existing one: if \"feature\" exists, that's the name, or\nif \"featURE\" exists, *that* is the name that is used.\n\nSo, if and when Git stores a branch name or component as a file-\nsystem file or directory name *and* the system itself imposes this\ncase-folding match-some-existing-name scheme, Git's case\ndistinction -- the fact that Git considers \"feature\" and \"Feature\"\nentirely different names -- is lost. Git is sure these are\ndifferent and will stay different, but they aren't and don't.\n\nWhen Git reads these names back later, it finds the system's\nnames, rather than the ones Git attempted to store. Git believes\nthe system's names, rather than its own.\n\nSometimes, however, Git stores branch names in memory or in\nfile data, where this kind of case-folding never occurs. During\nsuch periods, feature/git_repo and Feature/git_repo remain\ndifferent, distinct branch names.\n\nTo reproduce the problem, then, you must:\n\n 1. mix a case-sensitive system (e.g., a typical Linux setup\n    as found on GitHub) with a case-insensitive one (e.g., a\n    typical Windows or macOS system);\n\n 2. use the case-insensitive one yourself -- using the case-\n    sensitive system you will see branch names as they actually\n    appear, since they are never converted by the OS / file-system;\n\n 3. set up the problem; and\n\n 4. make sure Git stores the branch names in directories and\n    files, rather than in the .git/packed-refs file.\n\nThe cure for this would be for Git to stop using the file system's\nnames directly, the way it does now. There are some long term\nprojects to make this happen, but little progress has happened\nwith them.\n\nUntil then, the way to avoid the problem is simple:\n\n A) insist that everyone use the same kind of OS, and/or\n B) be careful not to depend on case differences.\n\nMethod (A) tends to be impractical but method (B) is easy: just\nmake sure all users use all-lowercase all the time, at least for\nbranch names. It's not very nice, but it's practical.\n\nChris\n"}]}