[clone to a case-sensitive medium, did not help]

[Uwe Brauer]

>>> "RW" == Rainer Woitok <rainer.woitok at gmail.com> writes:

> Uwe,
> On Saturday, 2021-06-05 18:21:53 +0200, you wrote:

>> ...
>> Ok, that finally worked, there where quite a couple of these files. So
>> now I can access the branch, but not *all* changesets (namely those with
>> the name collisions, I cannot, sigh)

> But you can access them  on your case sensitive USB stick.   May be it's
> some work, may be it's slow, but it's doable there.

Right, but on the long term it is not, and that is why I have to
reformat the disk.

The funny thing is I found 
https://www.macworld.com/article/233319/how-to-convert-a-case-sensitive-mac-hfs-partition-into-a-case-insensitive-one.html

which describes the other way. I find it absurd in 2021 to have a case
insensitive file system, just because some software companies prefer to
live in the 80, sigh, shrug





> Things that come to mind to find the collisions:

>    hg manifest --all | grep -i cali

>    # Provided ther isn't a ".hgignore" file in the repository itself:

>    HGPLAINEXCEPT= HGRCPATH= hg status | grep -i cali

>    cd $correct_dir ; ls * | grep -i cali

Just that you mentioned a hgignore file, yes I do have them, just
because a lot of my repositories contain latex files and I don't want
all sort of auxiliary files to be tracked, so I had the _brilliant_ idea
to add the case sensitive files to the hgignore file, but it did not
help.

BTW, I mentioned the old extension hgfold, that cannot be found. I
wonder how this was supposed to work, and on a second thought

@developers what about a extension that would allow change sets with
case conflict.

>> ...
>> My conclusion is:
>> 
>> Be careful with recent MacOs version, they are less unix like than you
>> think!

> It's not only a MacOS problem.   So I would generalize:  be careful with
> case agnostic operating systems as for instance Widoze (and thus Cygwin)
> as well as MacOS.  And keep in mind that at least in the case of Windoze
> the culprit is the  operating system  rather than the file system:  NTFS
> (originally designed by Microsoft)  DOES in fact  distinguish file "XxX"
> from file "xXx" when used under Linux.

Sigh, this is frankly beyond me, no polite word occurs to me to describe
that.

Uwe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5673 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20210606/c7ad3a38/attachment.p7s>