On Wed, Feb 23, 2011 at 10:56, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Johan Herland <johan@xxxxxxxxxxx> writes:
>
>> Are there better suggestions on how to deal with this?
>
> Just from the top off my head, perhaps you can go to the same route as
> symbolic link support on filesystems that are not symlink-capable?
I don't know how that helps here Junio. On those systems we write a
text file holding the symlink contents. That text file name is at
least still unique in the working directory.
Perhaps instead the "colliding file" becomes a directory that stores
all of the files below it, each with a unique name and a table of
contents, e.g.:
foo.txt/
git-contents:
file-A foo.TXT
file-B FOO.txt
file-A:
... the contents of foo.TXT ..
file-B:
... the contents of FOO.txt ..
It would be hard to work with in the index, and the project's build
system might fail, but at least the user can edit both files using
normal tools in the working tree, and can see which one is which using
the magic git-contents file.
This is such an odd corner case though, we need really good tests for
it, because it won't come up in daily usage very often. :-(
--
Shawn.
--
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