Bug: git pull output and case sensitivity.

Bug: git pull output and case sensitivity.

[dooagain]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.

What did you expect to happen? (Expected behavior)

I expected the output of `git pull` to accurately tell me about new branches.

What happened instead? (Actual behavior)

The output from `git pull` repeatedly claims that remote branches that differ in casing only to my local ref are always considered "new" even when they exist locally and are in sync with the remote branch.

What's different between what you expected and what actually happened?

Here is one example from the output from `git pull`:

* [new branch]              bug/#30k8z31/fixing_affordable_merge_fields -> origin/bug/#30k8z31/fixing_affordable_merge_fields

This is my local ref file:

.git/refs/remotes/origin/Bug/#30k8z31/fixing_affordable_merge_fields

The contents of my local ref is the same commit hash as the remote branch.

Anything else you want to add:

To me this seems like `git pull` is working as expected, but the output seems incorrect.
This is problematic, because in the current repository there are hundreds of branches that generate this output
so when `git pull` actually does have a problem it is very easy to miss.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.40.0
cpu: arm64
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: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /opt/homebrew/bin/bash


[Enabled Hooks]

Re: Bug: git pull output and case sensitivity.

[Torsten Bögershausen]

On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.

What do you mean by "I configured my git repository" ?
The answer is already there, so let's re-rephrase it:
Are you working on a case-insensitive file system ?

What happens if you create a test directory, like this:
mkdir test-case
cd test-case
git init
git config --get  core.ignorecase

>
> What did you expect to happen? (Expected behavior)
>
> I expected the output of `git pull` to accurately tell me about new branches.
>
> What happened instead? (Actual behavior)
>
> The output from `git pull` repeatedly claims that remote branches that differ in casing only to my local ref are always considered "new" even when they exist locally and are in sync with the remote branch.
>
> What's different between what you expected and what actually happened?
>
> Here is one example from the output from `git pull`:
>
> * [new branch]              bug/#30k8z31/fixing_affordable_merge_fields -> origin/bug/#30k8z31/fixing_affordable_merge_fields
>
> This is my local ref file:
>
> .git/refs/remotes/origin/Bug/#30k8z31/fixing_affordable_merge_fields
>
> The contents of my local ref is the same commit hash as the remote branch.
>
> Anything else you want to add:
>
> To me this seems like `git pull` is working as expected, but the output seems incorrect.
> This is problematic, because in the current repository there are hundreds of branches that generate this output
> so when `git pull` actually does have a problem it is very easy to miss.
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.40.0
> cpu: arm64
> 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: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
> compiler info: clang: 14.0.0 (clang-1400.0.29.202)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /opt/homebrew/bin/bash
>
>
> [Enabled Hooks]

Re: Bug: git pull output and case sensitivity.

[Jeff King]

On Sun, Mar 19, 2023 at 07:22:40AM +0100, Torsten Bögershausen wrote:

> On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> > Thank you for filling out a Git bug report!
> > Please answer the following questions to help us understand your issue.
> >
> > What did you do before the bug happened? (Steps to reproduce your issue)
> >
> > I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.
> 
> What do you mean by "I configured my git repository" ?
> The answer is already there, so let's re-rephrase it:
> Are you working on a case-insensitive file system ?
> 
> What happens if you create a test directory, like this:
> mkdir test-case
> cd test-case
> git init
> git config --get  core.ignorecase

I think this is kind of a red herring, isn't it? The bug report is about
refs, and I don't think those really respect core.ignorecase either way,
and inconsistencies are known to happen on case-insensitive filesystems
(because the refs are sometimes case-sensitive and sometimes not
depending on whether they are packed or loose in the filesystem).

So I think this is just a known gotcha, and the path forward is probably
a new ref storage format that doesn't rely on storing names directly in
the filesystem (reftable, or some system based on packed-ref slices).

-Peff

Re: Bug: git pull output and case sensitivity.

[dooagain]

I'm not sure if this is helpful, but I documented a simple way to recreate the issue I am seeing in the README in the https://github.com/spencerdcarlson/test-casing repository.

------- Original Message -------
On Monday, March 20th, 2023 at 11:16 AM, Jeff King <peff@peff.net> wrote:


> On Sun, Mar 19, 2023 at 07:22:40AM +0100, Torsten Bögershausen wrote:
> 
> > On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> > 
> > > Thank you for filling out a Git bug report!
> > > Please answer the following questions to help us understand your issue.
> > > 
> > > What did you do before the bug happened? (Steps to reproduce your issue)
> > > 
> > > I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.
> > 
> > What do you mean by "I configured my git repository" ?
> > The answer is already there, so let's re-rephrase it:
> > Are you working on a case-insensitive file system ?
> > 
> > What happens if you create a test directory, like this:
> > mkdir test-case
> > cd test-case
> > git init
> > git config --get core.ignorecase
> 
> 
> I think this is kind of a red herring, isn't it? The bug report is about
> refs, and I don't think those really respect core.ignorecase either way,
> and inconsistencies are known to happen on case-insensitive filesystems
> (because the refs are sometimes case-sensitive and sometimes not
> depending on whether they are packed or loose in the filesystem).
> 
> So I think this is just a known gotcha, and the path forward is probably
> a new ref storage format that doesn't rely on storing names directly in
> the filesystem (reftable, or some system based on packed-ref slices).
> 
> -Peff

Re: Bug: git pull output and case sensitivity.

[Torsten Bögershausen]

On Mon, Mar 20, 2023 at 06:01:30PM +0000, dooagain wrote:
> I'm not sure if this is helpful, but I documented a simple way to recreate the issue I am seeing in the README in the https://github.com/spencerdcarlson/test-casing repository.

It is helpful,  thanks.
In general, we prefer to have all informartion in emails ;-)
Anyway.

To reply on Peff's comment:

>So I think this is just a known gotcha, and the path forward is probably
>a new ref storage format that doesn't rely on storing names directly in
>the filesystem (reftable, or some system based on packed-ref slices).

Yes, it is.
The thing is, that Git at the moment is unable to handle to branches
like Foo and foo on case-insensitive file systems.
Because branch names are stored as files, and that doesn't typially work
well under Windows or MacOs.

As a workaround,
git pack-refs
can be used.

side-note 1: a better backend for refs may make it's way into Git
in the long term.

side-note 2:
I always recommend to stick to a naming convention when working in
a cross-platform project.
You can keep filenames only lowercase.
That is debatable, some people prefer camel-case rather then snake-case.
So go for either way.
But the same restriction/recommendation is valid for branch names as well,
stick to one convention and avoid possible collisions under Mac or Windows.

Or run `git pack-refs`, but be aware the the performance may suffer,
if you use zillions of refs.

HTH
/Torsten

>
> ------- Original Message -------
> On Monday, March 20th, 2023 at 11:16 AM, Jeff King <peff@peff.net> wrote:
>
>
> > On Sun, Mar 19, 2023 at 07:22:40AM +0100, Torsten Bögershausen wrote:
> >
> > > On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> > >
> > > > Thank you for filling out a Git bug report!
> > > > Please answer the following questions to help us understand your issue.
> > > >
> > > > What did you do before the bug happened? (Steps to reproduce your issue)
> > > >
> > > > I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.
> > >
> > > What do you mean by "I configured my git repository" ?
> > > The answer is already there, so let's re-rephrase it:
> > > Are you working on a case-insensitive file system ?
> > >
> > > What happens if you create a test directory, like this:
> > > mkdir test-case
> > > cd test-case
> > > git init
> > > git config --get core.ignorecase
> >
> >
> > I think this is kind of a red herring, isn't it? The bug report is about
> > refs, and I don't think those really respect core.ignorecase either way,
> > and inconsistencies are known to happen on case-insensitive filesystems
> > (because the refs are sometimes case-sensitive and sometimes not
> > depending on whether they are packed or loose in the filesystem).
> >
> > So I think this is just a known gotcha, and the path forward is probably
> > a new ref storage format that doesn't rely on storing names directly in
> > the filesystem (reftable, or some system based on packed-ref slices).
> >
> > -Peff

Re: Bug: git pull output and case sensitivity.

[dooagain]

This is probably overkill, but here is a script that replicates the issue

#! /usr/bin/env bash

# WARNING
# These are dangerous commands that create and delete
# disk volumes. Uncomment and execute at your own risk.

# [BEGIN DANGEROUS COMMANDS]
# 
# This is the command to "cleanup" or remove the newly created Volume.
# This will delete the Volume with an id of `disk1s9` that is going to
# change depending on your drive setup. Execute `diskutil list` to see 
# general disk info
#
# `diskutil apfs deleteVolume disk1s9`
#
# Create a case sensitive volume
# `diskutil apfs addVolume disk1 APFSX Casesensitive` # disk1s9
#
# [END DANGEROUS COMMANDS]

SCRIPT_DIR=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &> /dev/null && pwd)
REMOTE=/Volumes/Casesensitive/casing
# Set REMOTE="${SCRIPT_DIR}/casing-remote"
# If you do not want to create a case sensitive volume
REPO="${SCRIPT_DIR}/casing-bob"
REPO_OTHER="${SCRIPT_DIR}/casing-alice"

rm -rf "${REPO}" "${REPO_OTHER}" "${REMOTE}" && \
  mkdir "${REPO}" "${REPO_OTHER}" "${REMOTE}" && \
  cd "${REMOTE}" && \
  git init --bare && \
  cd "${REPO}" && \
  git init && \
  echo "#casing" > README.md && \
  git add README.md && \
  git commit -m "init commit" && \
  git branch -M master && \
  git remote add origin "${REMOTE}" && \
  git push -u origin master && \
  git clone "${REMOTE}" "${REPO_OTHER}" && \
  cd "${REPO}" && \
  git checkout -b Bug/foo && \
  touch foo && \
  git add foo && \
  git commit -m "adding foo file" && \
  git push --set-upstream origin Bug/foo && \
  cd "${REPO_OTHER}" && \
  git checkout -b bug/bar && \
  touch bar && \
  git add bar && \
  git commit -m "added bar file" && \
  git push --set-upstream origin bug/bar && \
  cd "${REPO_OTHER}" && \

  # casing-alice always thinks that Bug/foo is a new branch
  # because it has a loacl ref of ".git/refs/remotes/origin/bug/bar"
  # so it doesn't know Bug/foo and bug/foo are the same branch.
  # It does seem that local "bug/foo" 
  # is in sync with remote "Bug/foo" despite the warning

  git pull
  git pull


------- Original Message -------
On Monday, March 20th, 2023 at 1:12 PM, Torsten Bögershausen <tboegi@web.de> wrote:


> On Mon, Mar 20, 2023 at 06:01:30PM +0000, dooagain wrote:
> 
> > I'm not sure if this is helpful, but I documented a simple way to recreate the issue I am seeing in the README in the https://github.com/spencerdcarlson/test-casing repository.
> 
> 
> It is helpful, thanks.
> In general, we prefer to have all informartion in emails ;-)
> Anyway.
> 
> To reply on Peff's comment:
> 
> > So I think this is just a known gotcha, and the path forward is probably
> > a new ref storage format that doesn't rely on storing names directly in
> > the filesystem (reftable, or some system based on packed-ref slices).
> 
> 
> Yes, it is.
> The thing is, that Git at the moment is unable to handle to branches
> like Foo and foo on case-insensitive file systems.
> Because branch names are stored as files, and that doesn't typially work
> well under Windows or MacOs.
> 
> As a workaround,
> git pack-refs
> can be used.
> 
> side-note 1: a better backend for refs may make it's way into Git
> in the long term.
> 
> side-note 2:
> I always recommend to stick to a naming convention when working in
> a cross-platform project.
> You can keep filenames only lowercase.
> That is debatable, some people prefer camel-case rather then snake-case.
> So go for either way.
> But the same restriction/recommendation is valid for branch names as well,
> stick to one convention and avoid possible collisions under Mac or Windows.
> 
> Or run `git pack-refs`, but be aware the the performance may suffer,
> if you use zillions of refs.
> 
> HTH
> /Torsten
> 
> > ------- Original Message -------
> > On Monday, March 20th, 2023 at 11:16 AM, Jeff King peff@peff.net wrote:
> > 
> > > On Sun, Mar 19, 2023 at 07:22:40AM +0100, Torsten Bögershausen wrote:
> > > 
> > > > On Sat, Mar 18, 2023 at 07:21:10PM +0000, dooagain wrote:
> > > > 
> > > > > Thank you for filling out a Git bug report!
> > > > > Please answer the following questions to help us understand your issue.
> > > > > 
> > > > > What did you do before the bug happened? (Steps to reproduce your issue)
> > > > > 
> > > > > I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.
> > > > 
> > > > What do you mean by "I configured my git repository" ?
> > > > The answer is already there, so let's re-rephrase it:
> > > > Are you working on a case-insensitive file system ?
> > > > 
> > > > What happens if you create a test directory, like this:
> > > > mkdir test-case
> > > > cd test-case
> > > > git init
> > > > git config --get core.ignorecase
> > > 
> > > I think this is kind of a red herring, isn't it? The bug report is about
> > > refs, and I don't think those really respect core.ignorecase either way,
> > > and inconsistencies are known to happen on case-insensitive filesystems
> > > (because the refs are sometimes case-sensitive and sometimes not
> > > depending on whether they are packed or loose in the filesystem).
> > > 
> > > So I think this is just a known gotcha, and the path forward is probably
> > > a new ref storage format that doesn't rely on storing names directly in
> > > the filesystem (reftable, or some system based on packed-ref slices).
> > > 
> > > -Peff

Bug: git pull output and case sensitivity.

[dooagain]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

I configured my git repository to ignore case by executing `git config core.ignorecase true` then I executed `git pull` multiple times.

What did you expect to happen? (Expected behavior)

I expected the output of `git pull` to accurately tell me about new branches.

What happened instead? (Actual behavior)

The output from `git pull` repeatedly claims that remote branches that differ in casing only to my local ref are always considered "new" even when they exist locally and are in sync with the remote branch.

What's different between what you expected and what actually happened?

Here is one example from the output from `git pull`:

* [new branch]              bug/#30k8z31/fixing_affordable_merge_fields -> origin/bug/#30k8z31/fixing_affordable_merge_fields

This is my local ref file:

.git/refs/remotes/origin/Bug/#30k8z31/fixing_affordable_merge_fields

The contents of my local ref is the same commit hash as the remote branch.

Anything else you want to add:

To me this seems like `git pull` is working as expected, but the output seems incorrect.
This is problematic, because in the current repository there are hundreds of branches that generate this output
so when `git pull` actually does have a problem it is very easy to miss.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.40.0
cpu: arm64
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: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /opt/homebrew/bin/bash


[Enabled Hooks]