Re: Cloned repository has file changes -> bug?

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 6, 2018, 13:19 UTC
Message-ID: <CACsJy8A-KCzMCK34w_qNOQH2urwoQ-NmFZ+iR6Hyc3TQjGz1fg@mail.gmail.com>
In-Reply-To: <CD3563ED-5E0D-4238-A664-4F2335598FE2@kuleuven.be>

On Tue, Feb 6, 2018 at 8:09 PM, Filip Jorissen <filip.jorissen@kuleuven.be> wrote:

Show 5 quoted lines

> Hi all,
>
> Thank you for your quick responses. I was able to resolve the problem based on your feedback!
>
> Based on this experience, I would like to suggest that git is somehow able to avoid these problems by doing a case check itself rather than relying on the host OS for this?

Git itself can't resolve the problem. Case checking is just a side problem. You have two paths, only one of which can be checked out by your OS. How can Git know which one to checkout?

Git could pick one at random and hide the other (using sparse checkout, behind the scene). But that can still surprise the user "how come I see this content (of file "AAA") while the other user see another content (of file "aaa")?"

I don't see a good solution for this. I think the best we could do is warn earlier at clone time "trouble ahead! Your repository and your OS don't like each other!" so that users won't get puzzled at "git status" later. Would that help?

> Kind regards!
>
> Filip

-- 
Duy