On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:
<yousortofaskedforit>
Well, I can see no good reason for symrefs, except for backwards
compatibility! Modern systems do support symlinks, you know?
You misunderstood me here. I meant backward compatibility with git
wrappers, not with old operating systems.
I meant, the only reason we don't want symrefs to be used by default is
because there are wrappers around git that only work with symlinks. So,
if we change the default behavior in git now, those wrappers will break
on new repositories.
Let´s face it. The main target for git is not Windows users. If we really
want to support all idiocies of all possible ones, how about this one:
If I clone a repository to a USB stick on cygwin, and try to access it
from my iBook, it does not work, because for *backward compatibility*
reasons, files fitting the 8.3 format are stored in UPPER CASE.
So, I would like to have support for UPPER CASE files in .git, please? And
since I cannot do my own testing, please could you force everybody´s git
to write OBJECTS and MASTER in UPPER CASE?
That was pretty funny :-)
Actually, what's different about symlinks is that they go beyond the
paradigm of one data stream per file. There are two data streams
accessible through the symlink, one being the data in the file it points
to, and the other being the path to that file.
This doesn't map well to many data transfer protocols. We don't want
git to work only over protocols that have explicit support for symlinks.
One example is http, sometimes the only protocol allowed to transcend
corporate firewalls.
Another, more controversial example is CVS. Sourceforge doesn't support
git, but I could store my git database in Sourceforge CVS, and thus
share it with other contributors. Not being able to put .git/HEAD there
would be an annoyance.
I believe Cygwin developers were actually more concerned about symlinks
damaged by SMB than about any issues with storing them locally. After
all, Cygwin is quite good at emulating POSIX, including symlinks.
Returning to your example, 8.3 format is a problem with storage. Those
are behind us. It's problems with transfer that are going to limit us.
--
Regards,
Pavel Roskin