Re: symbolic link management in git-archive

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Sergio Callegari schrieb:
> I have a project where I need to have the same content in multiple places,
> otherwise development tools are not happy.
> Since I do most of the development on Linux, I use symbolic links. This is very
> good, not just because I save space, but particularly because I am sure that the
> content cannot loose coherency (which would be very bad) at the different
> places.
> 
> Every now and then, to distribute snapshots of the project, I run git archive to
> make a zip file, that I give to other people.  Unfortunately, some of them use
> Windows, where the symbolic links appear as one-liner text files. And obviously
> they cannot compile anything and they complain.
> 
> So I would like git archive to be able to make zip archives with the symbolic
> links /resolved/.

Windows 2000 and up has support for symbolic links; it's just strangely
restricted, e.g. on Windows 2000 you can only link to directories and
you have to use tools that aren't shipped with the OS to create them.
Microsoft even calls them differently; here's a good starting point for
more information: http://en.wikipedia.org/wiki/NTFS_junction_point

Arguably, your unzip program should create junction points for symlinks
in zip files.  I wouldn't be surprised if none of the existing ones
support that, though; junction points have been left undocumented for a
long time.  It's also possible that they'd understand a different zip
dialect for symlinks than the Info-Zip one produced by git-archive.

Would it be practical for you to distribute a junction point creation
tool like Mark Russinovich's Junction (except that Junction's EULA
forbids redistribution under most circumstances; see here:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx)
and a script that creates these symlinks for your audience?


It's harder for git-archive to support following symlinks than for e.g.
GNU tar.  The reason is that the former operates on git objects, not
files, directories or symlinks.  In order to follow a symlink it would
need to evaluate the symlink, follow it and then add actual files and
directories to the archive.

For your purposes, perhaps a slightly different implementation might be
sufficient: namely to follow only relative symlinks that point to
tracked objects.  That way you still get a repeatable result and (most
importantly) git-archive doesn't need to look at files and directories,
it can stay safely in git land.  Would such a way of operation be useful
to you?

Thanks,
René