Re: symbolic link management in git-archive

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Mar 31, 2008, 20:44 UTC
Message-ID: <47F14D4A.2020403@lsrfire.ath.cx>
In-Reply-To: <loom.20080327T175844-199@post.gmane.org>

Sergio Callegari schrieb:

Show 14 quoted lines

> 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é