On 28/08/07, Andreas Ericsson <ae@xxxxxx> wrote:
> Reece Dunn wrote:
> > On 28/08/07, Andreas Ericsson <ae@xxxxxx> wrote:
> >> Reece Dunn wrote:
> >>> Hi,
> >>>
> >>> Running the following:
> >>>
> >>> echo "hello" > foo
> >>> git add foo && git commit -m "move test (1)"
> >>> git mv foo Foo
> >>>
> >>> using a case-insensitive filesystem (this was done running git 1.5.0.3
> >>> and git 1.5.1.3 on Windows using cygwin), I get the following error:
> >>>
> >>> fatal: destination exists, source=foo, destination=Foo
> >>>
> >>> Are there any plans to support this on case-insensitive filesystems,
> >>> or is it going to remain broken?
> >>>
> >> It's going to remain in the state it is, although I disagree that that
> >> state is broken. Adding case-sensitivity to a content tracker on a
> >> case-insensitive file system would be quite a lot of work for a very
> >> small gain.
> >
> > I'm not suggesting adding case sensitivity to the content tracker.
> >
>
> But without case sensitivity in the tracker there's no way "mv foo Foo"
> can work on a filesystem level. You'd have to jump some sort of hoop.
I meant s/sensitivity/insensitivity/ in this context. I was not
suggesting dropping git's case *sensitivity* to support case
insensitive filesystems. That would be an insane idea as there would
be a _loss_ of information, which is bad and wrong on so many levels.
> >> As usual, should you present some small and elegant piece of code that
> >> makes git capable of dealing with this while running with no slowdown
> >> at all on sane systems, I'm sure it'd be accepted, or at least very
> >> thoroughly discussed by the heavy names on the list.
> >
> > I have tried the following:
> >
> > git mv foo foo.tmp
> > git mv foo.tmp Foo
> >
> > which correctly reports:
> >
> > renamed: foo -> Foo
> >
>
> Yes, because then you give the filesystem some leeway in that it
> doesn't have to create two files with conflicting hash entries.
> And that's the hoop, I suspect.
>
> Some really insane filesystems have the odd ability to report case
> sensitively while not actually supporting it (VFAT, I think, displays
> this absurd capability). Either way, the tools manipulating the file-
> system still only sees what the filesystem reports, so...
NTFS supports this absurd behaviour as well. Therefore, this applies
to all Windows-based platforms, which means that changing the case of
a file on Windows is broken.
> > However, given that the double move works as expected, I don't see
> > this as being a big issue.
> >
>
> True. What happens when you "git mv -f foo Foo"?
I get:
$ git mv -f foo Foo
Warning: destination exists; will overwrite!
fatal: Huh? Cache entry for Foo unknown?
and:
$ git status
# Untracked files:
#
# Foo
- Reece
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
