R0b0t1 <r03...@gmail.com> wrote: > On Tue, May 15, 2018 at 11:15 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> AFAIK symlinks aren't allowed in the gentoo tree [...] >> >> Tho perhaps that can be reevaluated. [...] > > Cygwin and MSYS(2) are currently mostly supported by Prefix [...]
For rsync users, the non-symlink policy is not necessary: They could simply pass the option --copy-links to get a working tree (of course, correspondingly longer). For git users (essential for overlays!), I do not know a simple way. It might be possible to set up appropriate git hooks, but that might be tricky: The hooks would need to apply before the files are actually checked out, and it might become even more tricky if one does not want that subsequent git commands do consider the transformation as a local modification. For git perhaps an opposite approach might be easier: One could provide hooks which every git user is supposed to use which manage symlinks and/or copies. More precisely, these hooks should have a symlink and a non-symlink mode (depending on whether the underlying (file)system can generate symlinks which can easily and quickly be detected), and the tree would need to contain a symlinks.dat file with a list of symlinks, and a .gitignore containing the symlinks. During checkout, the hooks should simply generate the corresponding symlinks/files (depending on symlinks.dat) according to the stored list of symlinks. During checkin in symlink mode, these hooks automatically update symlinks.dat and .gitignore so that most developers simply can use/modify symlinks transparently. During checkin in non-symlink mode the hook does nothing: Developers who checkin on filesystems without symlink have to update these 2 files manually, of course, when they want to create/remove/rename a symlink. Maybe one could provide corresponding helper scripts for those developers with non-symlink-aware filesystems if necessary.
