> A symlink?! This can only cause problems: > - When 'git' is run on a Windows system (not Cygwin), AFAIK there are > no symlinks.
In which case, git treats the file as a single line text, whose contents would correspond to the symlink, but the contents of the git tree make it obvious (via the different object mode) that it is a link. > - When 'git' is run on Linux on a vfat file system, there are > - no symlinks. Ditto. git can already work around such deficient file systems when it comes to versioning the file, and hopefully no one is crazy enough to actually try developing git on such a file system. But makeinfo, copy and others do not work around such deficient file systems, and one cannot expect every tool to do so. > - When you use 'tar' with option 'h' to copy the directory, the > copy will be different from the original: it will have the > symlink replaced by its target's contents. Which is perfectly fine - the copy in gnulib is for reference, and whether it is a symlink or a copy shouldn't matter. It just made my life as autoconf maintainer easier to be able to add a line to cfg.mk that does 'cp gnulib/doc/fdl.texi autoconf/doc/', http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=5bf2204#patch2 That will not work if you do it on a vfat filesystem, all you will get is a single line text file; which will produce the wrong info manual. It will also not help if you wish to use fdl.texi directly on a vfat file system. The problem is not git handling things like this, but other programs. > Please, can't you make fdl.texi a regular file? Either with > contents > > @include fdl-1.3.texi > > or as a copy of fdl-1.3.texi? This is a nice and simple solution.
