Git symlinks support?


I saw the news and decided to give this a go. It seems to work good as a first step.

One thing I noticed is that git symlinks aren’t enabled. Is there any way to configure the git config options before the clone? Like git config --global core.symlinks true.

1 Like

I realize this is old, but this would be great if this could be supported. I have a project that has a softlink and it took me forever to figure this out. My local Windows virtual machine didn’t have this issue, only travis Windows. I had code that was reading the file and was really confused why it was just a text file with the path to the source file.

If this can’t be set globally for all travis projects, is there a way we can customize the git command from the travis yaml file?

Sorry about the long silence.

This seems a reasonable option to have.


Pardon for my ignorance, have been trying to find the answer to my question elsewhere but have failed to… when does this become available upstream? I have been trying to incorporate this to our experimental windows travis runs, because we need to add some symlinks to get behat working… and it seems that the option is still completely ignored.

Thanks, ciao :slight_smile:

Please point to a build log URL that it’s not getting the results you want. Thanks.

Hey, basically the last 4-5 runs of the “travis_windows_exp” branch @

I’ve tried there changing the order of the autocrlf and symlinks settings, adding and remove the hyphens (because I’m never sure about them)… and in all them I can see in the logs that the git config is issued for the autocrlf one, but nothing for the symlinks one.

Ciao :slight_smile:

You will notice that autocrlf isn’t working, either. Because your git value is an array and not a hash.

What you need is:

  autocrlf: true
  symlinks: true

As commented above, I just started trying combinations to verify everything. For example @ Experimenting with behat... · stronk7/moodle@b33b8d8 · GitHub I tried that way.

Ok, going to verify with both set to boolean, just in case the autocrlf is “killing” the symlinks one. In fact I think I also tried with singular… is it really singular? Anyway, trying…

Uhm, I’ve tried here with the singular and no luck. Also, I think that “input” is correct one, from the user docs. That’s exactly what I want, keeping files as they are @ origin.

Ciao :slight_smile:

Edited: And this back to plural, same:

Ooops. I just realized that you are setting symlink: true, not symlinks. (I’ve updated my response above.)

Heh, I tried both singular and plural! Also updated my reply :slight_smile:

If you dump git config -l, you should see core.symlinks=true.

If your build is failing, I must think that there is something else at play.

Ok, will try dumping… I just was expecting to see in the logs the undelying git command being executed, much like the autocrlf one is shown. Seeing nothing is what made me think if the feature was rolled everywhere or not.

Thanks! Will continue trying…

Just confirming… it’s not being set, git config -l shows false. Wow… in fact… it shows it twice!


Note i was just hopping that was enough to allow soft-links (that I need in those jobs to be able to test behat under windows) to work ok. In fact the jobs are failing because of that (the ln -s ends failing).

This is curious. I honestly don’t know what’s happening here.

aha, repo, user vs global levels (pity it just doesn’t report the “active” conf):

So it seems that it’s being applied ok (both autocrlf and symlinks) and more local config wins, so far. So all right.


  1. The git config symlinks = true execution is not shown in logs (that’s confusing).
  2. Soft links continue not working here (a “cp” is attempted and it fails).

Will try some alternative somehow… thanks for the support!

Hmmm. So, on Windows,

file:C:/Program Files/Git/etc/gitconfig	core.symlinks=false

wins? :thinking:

I did read somewhere (sorry, haven’t the resource at hand) that the most-close (near, local) configuration wins. Aka: repo == wins over ==> user == wins over ==> global.

So, if that’s correct, then your approach is ok. Will try to find the reference…

Here it is, if I’ve understood it ok, the “latest” (or more local) value wins. It also can be checked using git config --get xxxx, it seems.

Given that, your approach seems correct (setting it to travis user “wins” over system/global default).