Re: Bug: git pull output and case sensitivity.

From: dooagain <dooagain@protonmail.com>
Date: Mar 22, 2023, 17:44 UTC
Message-ID: <RzFzlUstO3B5yEeHQADOAFSBeeieGLLv_Vbj4B9yss_8qB_kshBK5NvvOBKlfnHPg_7GDhdyWGxmak-jyczZCyjihDnqMp2oZRpiCyn6wU0=@protonmail.com>
In-Reply-To: <20230320191210.jzzq5c2ssxcltvoc@tb-raspi4>

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:

Show 79 quoted lines

> 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