"case folding" error when using hg-git to clone repository
Ben Fritz
use git directly, but I don't want to need to learn a new tool just to
get the source to build eclim with all the latest bugfixes, so I chose
instead to install the hg-git extension to my Mercurial installation,
allowing me to clone git repositories and interact with them using
Mercurial.
But, apparently there's a file Test.h and another file test.h in the
same directory somewhere in the project tree (I can paste the exact
location at home this evening if needed...I gave up in disgust last
night when my 30-minute pull+update failed with a "case folding"
error). On Windows, Mercurial cannot update to a version containing
both these files, since Windows is a case-insensitive file system. I'm
not sure how git handles it, but obviously Windows users cannot get a
working copy with both files included even if git allows them get a
copy of any of the other files. Mercurial with hg-git simply refuses
to give you ANY files in the revision, although I do have an empty
clone of the repository so the "update" is a local operation now, at
least.
Can this be fixed? Or is there something I can update to already which
has this issue resolved? I tried updating to both "default" and
"master" but did not try any of the other branches.
Eric Van Dewoestine
> I understand that most people grabbing the eclim source probably just
> use git directly, but I don't want to need to learn a new tool just to
> get the source to build eclim with all the latest bugfixes, so I chose
> instead to install the hg-git extension to my Mercurial installation,
> allowing me to clone git repositories and interact with them using
> Mercurial.
>
> But, apparently there's a file Test.h and another file test.h in the
> same directory somewhere in the project tree (I can paste the exact
> location at home this evening if needed...
I just checked in a change to move a couple files around which should
hopefully prevent this issue.
> I gave up in disgust last
> night when my 30-minute pull+update failed with a "case folding"
> error).
30 minutes to pull and update!? For comparison, I just cloned the
repos on my windows vm using git and it took a minute and a half at
about 400-500 KiB/s (it took under a minute in cygwin). I'm not sure
if hg-git is the cause of that huge time discrepancy, but 30 minutes
is pretty ridiculous, so I can understand your frustration.
> On Windows, Mercurial cannot update to a version containing
> both these files, since Windows is a case-insensitive file system. I'm
> not sure how git handles it, but obviously Windows users cannot get a
> working copy with both files included even if git allows them get a
> copy of any of the other files. Mercurial with hg-git simply refuses
> to give you ANY files in the revision, although I do have an empty
> clone of the repository so the "update" is a local operation now, at
> least.
I think git would just check the files out normally and then Windows
would probably overwrite the earlier test/Test.h with the later
alternate case file. It wasn't really a big deal since those files are
only used to run the cdt unit tests which no one but me does.
> Can this be fixed? Or is there something I can update to already which
> has this issue resolved? I tried updating to both "default" and
> "master" but did not try any of the other branches.
--
eric
Benjamin Fritz
> On 2012-02-10 07:03:47, Ben Fritz wrote:
>> I understand that most people grabbing the eclim source probably just
>> use git directly, but I don't want to need to learn a new tool just to
>> get the source to build eclim with all the latest bugfixes, so I chose
>> instead to install the hg-git extension to my Mercurial installation,
>> allowing me to clone git repositories and interact with them using
>> Mercurial.
>>
>> But, apparently there's a file Test.h and another file test.h in the
>> same directory somewhere in the project tree (I can paste the exact
>> location at home this evening if needed...
>
> I just checked in a change to move a couple files around which should
> hopefully prevent this issue.
>
Thanks, I'll take a look at home later. I want to go through the
process at home to get over any "gotchas" (like this one) before I try
it at work.
>> I gave up in disgust last
>> night when my 30-minute pull+update failed with a "case folding"
>> error).
>
> 30 minutes to pull and update!? For comparison, I just cloned the
> repos on my windows vm using git and it took a minute and a half at
> about 400-500 KiB/s (it took under a minute in cygwin). I'm not sure
> if hg-git is the cause of that huge time discrepancy, but 30 minutes
> is pretty ridiculous, so I can understand your frustration.
>
Well...it's really an unfair comparison. While hg-git may be part of
the issue, I am pretty sure the main cause is my low-end Dell from
around 2001/2002, with a Pentium 4 processor, Windows XP which hasn't
been wiped or anything since the computer was new, a failed CPU fan,
and the fact that I'm cloning to a 4GB hard drive I cannibalized out
of an even more ancient PC being thrown out by my school's CS
department while I was in college.
>> On Windows, Mercurial cannot update to a version containing
>> both these files, since Windows is a case-insensitive file system. I'm
>> not sure how git handles it, but obviously Windows users cannot get a
>> working copy with both files included even if git allows them get a
>> copy of any of the other files. Mercurial with hg-git simply refuses
>> to give you ANY files in the revision, although I do have an empty
>> clone of the repository so the "update" is a local operation now, at
>> least.
>
> I think git would just check the files out normally and then Windows
> would probably overwrite the earlier test/Test.h with the later
> alternate case file. It wasn't really a big deal since those files are
> only used to run the cdt unit tests which no one but me does.
>
That's interesting; I'm not sure which behavior I prefer. Honestly I
think somewhere in the middle would be best, it would be nice to be
able to get a working copy by adding --force to the update command or
something, but I can see the merits of failing an update by default if
you cannot get all the files due to system constraints.