onsdag 28 februari 2007 01:07 skrev Johannes Schindelin: >> > Basically, there is no proper way to solve it (other than switching to > Linux, but that goes without saying). > Your solution would fall short if one of the two files is changed. Since > they are supposed to be symlinks, the application expects them to be > identical, and weird sh*t happens. As will it when the file contain something completly different than expected. Another SCM does copies instead and that works, though it's not very beautiful, but the checkout "works" 99% of the time, rather than not at all. As you code Most apps won't care if the original and the copy are different, but the user may notice (or not...). > E.g. if you have a symlink "ln -s Makefile.host Makefile", and a script > which changes "Makefile.host", and a subdirectory Makefile accessing the > root Makefile, you will not be happy. If... > So, any way you go, if you have a repository containing symlinks, and you > have an OS which does not support symlinks, you are screwed. As I said, I've seen the scheme sort of work. I can still work with the checkout, though not entirely as I would like to work (but that includes the platform too). All tools can use a copy, none can use a textfile containing the pointed to file. > But since we already have a symlink in git.git, and _want_ to compile git > on MinGW nevertheless, we should support symlinks _somehow_. Even if that > means that advanced usage of symlinks will fail. > > I agree with Johannes here how to go about this partial "support" of > symlinks, since I cannot think of any sane way to retain the information > (where the symlink points to) in the index. Don't update the symblink. We know it's a link. You don't want to anyway in your non-symlink supporting environment, or add git-ln. -- robin - 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