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@xxxxxx> 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@xxxxxxxx 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
