Default to symlinks in Makefile

[ghost]

By default some Git files are built as hard links. Windows archiving
tools don't comprehend hard links in archives.

The installer "Git for Windows" already creates symlinks for these
files. This change would be an extension to that.

Using NeoSmart's ln.exe will make correct Windows symlinks in certain
cases, whereas other users can continue to use MinGW's ln.exe or even
Msysgit's ln.exe, in which ln -s simply makes a copy.

Some discussion
lists-archives.com/mingw-users/10388-flex-update

[kusma]

Won't a change like this start bloating the installation for people who doesn't use NeoSmart's ln-replacement?

[ghost]

True. Maybe a better option would be a variable, something like make LN='ln -s'. I will look into it.

[dscho]

I actually wonder whether what happens if we simply do not link git.exe to all the names of the built-in commands. What would break?

[kusma]

old scripts.

[dscho]

@kusma old scripts need fixing, then. The pain of keeping bugwarts-compatibility is too big in this case, IMHO.

[ghost]

@dscho you cant really omit the BUILT_INS because not all of them are symlinks to git.exe

[kusma]

@dscho I wasn't objecting to that ;)

[dscho]

@svnpenn built-ins are -- by definition -- commands that git.exe can run without spawning a new executable to do the job. They can be recognized by their lack of their own main() function; instead, they all come in cmd_() varieties and are listed builtin.h as well as in git.c's commands[] array. The only reason to hardlink them to the main Git executable are -- as @kusma suggested -- old scripts that still call things by their dashed name ('git-add' instead of 'git add').

[kusma]

Oh, I didn't mean to say that they were the only things that would break. But a quick peak didn't reveal anything obvious either. I guess the best way to find out would be to give it a go...

[kblees]

Call me stupid, but I don't understand what exactly you're trying to achieve with this change.

AFAICT, switching from hard links to symbolic links would reduce compatibility with both the Windows OS and Windows archiving tools:

• Windows XP supports hard links only
• MSYS tar supports hard links only
• Windows Compressed Folders (built-in archiving tool) and 7-zip (probably most popular open-source archiving tool) neither support hard links nor symbolic links
• Even archiving formats that DO support symbolic links on Unix (such as .tar, .zip) don't store whether the link target is a file or directory, so they don't support Windows symbolic links (except perhaps with vendor-specific extensions)

The discussion you linked to seems to conclude that the mingw package format shouldn't use any form of links for compatibility with Windows archivers.

Apart from that, hard links are faster (no link resolution necessary) and IMO much more robust than symbolic links (e.g. the link target can be moved or deleted without affecting the links). So there's probably good reason why the Makefile creates hard links by default.

[ghost]

The goal is a way to distribute Git Windows builds. If you build Git for Windows you have yourself over 100 hard links to git.exe. If you were going to distribute this build you could use either or 7-zip or tar to create an archive.

Both ways present a problem.

If you were to use 7-zip, this would not work because 7-zip does not recognize hard links. It would simply interpret each git built-in as its own file and youd be left with a huge archive.

If you were to use tar to create an archive then all is well, unless another Windows user decides to extract that archive with 7-zip, in which case the hard links would extract as 0 byte unusable files.

With symlinks, you could archive and extract the build on Windows without these problems. While I agree with kusma that symlinks shouldnt be the default, they should be an option at least.

[kblees]

With symlinks, you could archive and extract the build on Windows without these problems.

AFAIK, the 7z format doesn't support symbolic links at all. Anyway, I just tried to archive my Win7 Git installation with 7-zip. All symlinks (e.g. in libexec/git-core) extract to unusable 0-byte files instead of symlinks.

Am I missing something?

[ghost]

Am I missing something?

No. For some reason I thought 7-Zip worked with symlinks. A better option would be a way to disable building of built-ins altogether, as @dscho suggested.

[dscho]

Our PortableGit is already 7-zipped and has special-casing for the hard links. Note that the .7z files are hardly larger because 7-Zip is real good at detecting the identical content. However, the on-disk usage was still unbearably large, that's the reason we have that special-handling.

Unfortunately, I had to switch that special-handling off (see "Portable Git: include builtins as-are"). @svnpenn if you care a lot about this issue, you might want to dig out the corresponding email correspondence and figure out whether the issues persist or whether we can just kill the hard-linked files.

[ghost]

Git returns an error if you build with make install prefix=/c/git BUILT_INS=

install git.exe git-upload-pack.exe git-receive-pack.exe git-upload-archive.exe git-shell.exe git-cvsserver '/c/git/bin'
install: cannot stat `git-receive-pack.exe': No such file or directory
install: cannot stat `git-upload-archive.exe': No such file or directory
make: *** [install] Error 1

I made a post to the Git mailing list

thread.gmane.org/gmane.comp.version-control.git/196179

[kblees]

What about replacing the links with shell scripts, would that solve the backward compatibility problem?
I.e. libexec/git-core/git-status :=
#!/bin/sh
git status @*

[dscho]

@kblees sure, that'd work (and it would also make the offending scripts slower, providing more reasons to upgrade them).

[ghost]

I dont want to punish users with old scripts. I just want a way to build Git without the built-ins, as they are not needed for current scripts and complicate Windows distributions.

[hvoigt]

@svnpenn if you just want to be able to build git without the hardlinks how about providing a patch/pull request adding the NO_BUILTINS option you suggested on the mailinglist to the Makefile? Even if this does not get accepted upstream we can track it here first.

If nobody is working on this I will label the issue that it needs some volunteer.

[ghost]

I had kind of given up on it after hitting a brick wall with Junio Hamano, on the mailing list. I will try to make a patch to msysgit/git Makefile today

[dscho]

@svnpenn in Git for Windows we try to be a bit more pragmatic, so yes, it seems that we can give your patch a nice shelter here.

[dscho]

@svnpenn so we gave the patch a shelter but ran into problems (as you might have seen on this issue tracker)... I am inclined to close this pull request for that reason... do you agree?

[ghost]

Agree

[dscho]

@svnpenn thanks!