Git branch capitalisation bug?

Git branch capitalisation bug?

[Ilya Kamenshchikov]

What did you do before the bug happened? (Steps to reproduce your issue)
Created a branch "feature/macos_tests", pushed to remote as
"origin/feature/macos_tests".

What did you expect to happen? (Expected behavior)
remote branch "feature/macos_tests" to be created.

What happened instead? (Actual behavior)
remote branch name is "Feature/macos_tests" (capitalised). This
doesn't play nicely with not case sensitive macos FS.



[System Info]
git version:
git version 2.40.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01
PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64 x86_64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /usr/local/bin/fish


[Enabled Hooks]
pre-push
(remark: reproduced also when uninstalling this hook)

Raw output:

~ $ cd bosch/rlcore                                       (base) 12:11:42
~/b/rlcore (feature/macos_tests|✚2) $ git push            (base) 12:11:49
fatal: The current branch feature/macos_tests has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature/macos_tests

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

~/b/rlcore (feature/macos_tests|✚2) [128] $ git push --set-upstream
origin feature/macos_tests
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
Thank you for filling out a Git bug report!
remote:
remote: Create a pull request for 'feature/macos_tests' on GitHub by visiting:
remote:      https://github.boschdevcloud.com/CR/rlcore/pull/new/feature/macos_tests
remote:
To https://github.boschdevcloud.com/CR/rlcore.git
 * [new branch]        feature/macos_tests -> feature/macos_tests
branch 'feature/macos_tests' set up to track 'origin/feature/macos_tests'.
~/b/rlcore (feature/macos_tests|✚2) $ gl                  (base) 12:16:10
c001bc75 2023-04-13 | commit message (#514) (HEAD ->
feature/macos_tests, origin/main, origin/git_problems, origin/HEAD,
origin/Feature/macos_tests) [Rich..]

Best Regards,
--
Ilya Kamen

Re: Git branch capitalisation bug?

[Torsten Bögershausen]

On Thu, Apr 13, 2023 at 12:35:36PM +0200, Ilya Kamenshchikov wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
> Created a branch "feature/macos_tests", pushed to remote as
> "origin/feature/macos_tests".
>
> What did you expect to happen? (Expected behavior)
> remote branch "feature/macos_tests" to be created.
>
> What happened instead? (Actual behavior)
> remote branch name is "Feature/macos_tests" (capitalised). This
> doesn't play nicely with not case sensitive macos FS.
>
>
>
> [System Info]
> git version:
> git version 2.40.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01
> PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64 x86_64
> compiler info: clang: 14.0.0 (clang-1400.0.29.202)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /usr/local/bin/fish
>
>
> [Enabled Hooks]
> pre-push
> (remark: reproduced also when uninstalling this hook)
>
> Raw output:
>
> ~ $ cd bosch/rlcore                                       (base) 12:11:42
> ~/b/rlcore (feature/macos_tests|✚2) $ git push            (base) 12:11:49
> fatal: The current branch feature/macos_tests has no upstream branch.
> To push the current branch and set the remote as upstream, use
>
>     git push --set-upstream origin feature/macos_tests
>
> To have this happen automatically for branches without a tracking
> upstream, see 'push.autoSetupRemote' in 'git help config'.
>
> ~/b/rlcore (feature/macos_tests|✚2) [128] $ git push --set-upstream
> origin feature/macos_tests
> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> Thank you for filling out a Git bug report!
> remote:
> remote: Create a pull request for 'feature/macos_tests' on GitHub by visiting:
> remote:      https://github.boschdevcloud.com/CR/rlcore/pull/new/feature/macos_tests
> remote:
> To https://github.boschdevcloud.com/CR/rlcore.git
>  * [new branch]        feature/macos_tests -> feature/macos_tests
> branch 'feature/macos_tests' set up to track 'origin/feature/macos_tests'.
> ~/b/rlcore (feature/macos_tests|✚2) $ gl                  (base) 12:16:10
> c001bc75 2023-04-13 | commit message (#514) (HEAD ->
> feature/macos_tests, origin/main, origin/git_problems, origin/HEAD,
> origin/Feature/macos_tests) [Rich..]
>
> Best Regards,
> --
> Ilya Kamen

I am not sure, where this Capitalizations comes from.
I don't have an account on boschdevcloud.com to test.
Is it possible to reproduce it with a public repo ?
Otherwise, should we suspect boschdevcloud.com for it ?

Any other thoughts from anybody ?

Re: Git branch capitalisation bug?

[Junio C Hamano]

Torsten Bögershausen <tboegi@web.de> writes:

> I am not sure, where this Capitalizations comes from.
> I don't have an account on boschdevcloud.com to test.
> Is it possible to reproduce it with a public repo ?
> Otherwise, should we suspect boschdevcloud.com for it ?
>
> Any other thoughts from anybody ?

In the transcript I do not see any "git pull" done from the other
side, so the "origin/Feature/macos_tests" in the commit decoration
that can be seen in the last part of the transcript may have been
created locally.  Output from

 $ git ls-remote origin | grep macos_tests

might be a way to see which end of the connection has the issue.

Re: Git branch capitalisation bug?

[Ilya Kamenshchikov]

I've recollected the history of how this issue occurred more and did
few more tests. I'm now working with branch named "feature/git_repro":
1) The error first occurred when I worked with a colleague on a same
branch, and he really used capital "Feature/branch".
2) today, after initial push and doing git log, local git believes it
to be "Feature/repro_git", while `ls-remote` says it's
"feature/repro_git"
```
$ git checkout -b feature/repro_git
$ git push --set-upstream origin feature/repro_git
$ git log
commit 846df8e6d2f921d0ee2e7c427ca174fae291b040 (HEAD ->
feature/repro_git, origin/Feature/repro_git)
$ git ls-remote origin | grep repro
                      (base) 08:44:31
846df8e6d2f921d0ee2e7c427ca174fae291b040 refs/heads/feature/repro_git
```
3) So I conclude there must be some local information saying branch
has Capitalised name, while on remote all is normal.
$ ls .git/refs/remotes/origin
Feature/
# note: doesn't contain "feature/"
---
My wild speculation now: when I first checked out the branch
Feature/branch of my colleague, git has rewritten
.git/refs/remotes/origin/feature as capitalised Feature.
---
I will try to reproduce this on public GitHub later.

Best Regards,
--
Ilya Kamen

On Thu, Apr 13, 2023 at 10:34 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Torsten Bögershausen <tboegi@web.de> writes:
>
> > I am not sure, where this Capitalizations comes from.
> > I don't have an account on boschdevcloud.com to test.
> > Is it possible to reproduce it with a public repo ?
> > Otherwise, should we suspect boschdevcloud.com for it ?
> >
> > Any other thoughts from anybody ?
>
> In the transcript I do not see any "git pull" done from the other
> side, so the "origin/Feature/macos_tests" in the commit decoration
> that can be seen in the last part of the transcript may have been
> created locally.  Output from
>
>  $ git ls-remote origin | grep macos_tests
>
> might be a way to see which end of the connection has the issue.
>

Re: Git branch capitalisation bug?

[Chris Torek]

On Thu, Apr 20, 2023 at 12:08 AM Ilya Kamenshchikov
<ikamenshchikov@gmail.com> wrote:
> I've recollected the history of how this issue occurred more and did
> few more tests. I'm now working with branch named "feature/git_repro":
> 1) The error first occurred when I worked with a colleague on a same
> branch, and he really used capital "Feature/branch".

The bug -- or "feature", depending on how you believe this all
*should* work -- is simple in concept and difficult in
reproduction because there are multiple moving parts.

Here's the concept:

 * In Git, branch names are always case sensitive.

 * But Git *sometimes* relies on the *OS* / file-system to
   implement this.

 * Some OSes / file-systems are case *in*sensitive.

When Git uses a case-INsensitive file-system to store a case-
sensitive branch name component, the OS / file-system loses the
case distinction. Exactly how that happens is up to the OS /
file-system, but we can see how common macOS and Windows systems
do it.

On these systems, when creating a file or directory, the *first*
creation attempt "wins". That is, if any command or process
goes to create a file or directory named "Feature", and no such
file or directory exists *now*, the file or directory is created
with precisely this set of casing. But if the file or directory
*already exists* in any casing (upper and/or lower), the system
uses the existing one: if "feature" exists, that's the name, or
if "featURE" exists, *that* is the name that is used.

So, if and when Git stores a branch name or component as a file-
system file or directory name *and* the system itself imposes this
case-folding match-some-existing-name scheme, Git's case
distinction -- the fact that Git considers "feature" and "Feature"
entirely different names -- is lost. Git is sure these are
different and will stay different, but they aren't and don't.

When Git reads these names back later, it finds the system's
names, rather than the ones Git attempted to store. Git believes
the system's names, rather than its own.

Sometimes, however, Git stores branch names in memory or in
file data, where this kind of case-folding never occurs. During
such periods, feature/git_repo and Feature/git_repo remain
different, distinct branch names.

To reproduce the problem, then, you must:

 1. mix a case-sensitive system (e.g., a typical Linux setup
    as found on GitHub) with a case-insensitive one (e.g., a
    typical Windows or macOS system);

 2. use the case-insensitive one yourself -- using the case-
    sensitive system you will see branch names as they actually
    appear, since they are never converted by the OS / file-system;

 3. set up the problem; and

 4. make sure Git stores the branch names in directories and
    files, rather than in the .git/packed-refs file.

The cure for this would be for Git to stop using the file system's
names directly, the way it does now. There are some long term
projects to make this happen, but little progress has happened
with them.

Until then, the way to avoid the problem is simple:

 A) insist that everyone use the same kind of OS, and/or
 B) be careful not to depend on case differences.

Method (A) tends to be impractical but method (B) is easy: just
make sure all users use all-lowercase all the time, at least for
branch names. It's not very nice, but it's practical.

Chris