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.
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?
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.
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.
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.
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.
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).
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…