On 2018-03-26 04:05, Ryan Schmidt wrote: > I ended up fixing it by copying the entire clone to a case-sensitive HFS+ > disk image, running "git checkout gis/LASzip" and "git checkout gis/laszip", > then copying the clone back to my case-insensitive HFS+ disk. If there was an > easier way to fix this, I'd love to know it for future reference.
Let's go back to the broken commit and simulate this on a new branch: $ git checkout -b laszip-broken e3710d6800e803ebaa9528d3bdb38fb2fcade513 $ git st -s M gis/laszip/Portfile The problem here is that you cannot get rid of local changes in the working tree, because two paths share the same file on disk. Every time you checkout one of the files, the other file no longer matches what git expects and is considered modified. You can break that by deleting the file from disk, so both paths known by git will have a consistent state on disk: deleted. $ rm gis/laszip/Portfile $ git st -s D gis/LASzip/Portfile D gis/laszip/Portfile Now we can pull the latest changes from the remote, which includes the commit that removed one of the files. Of course the deleted file is still missing, so git still considers this an uncommitted modification. $ git pull origin master ... $ git st -s D gis/laszip/Portfile To get rid of this state, we discard the local modification and restore the file with git checkout. $ git checkout gis/laszip/Portfile $ git st -s $ Now the working tree is clean again. Rainer
