Cargo build with dependencies fails on Cygwin referring to git-core/templates

[CMCDragonkai]

After trying cargo build --verbose on a project in Cygwin with a single dependency, this is the output:

 ± cargo build --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
Unable to update registry https://github.com/rust-lang/crates.io-index

Caused by:
  [2] Could not find '/cygdrive/c/cygwin64/usr/share/git-core/templates/' to stat: The system cannot find the path specified.

/cygdrive/c/cygwin64/usr/share/git-core/templates/ does exist, since I went there and saw stuff in it.

Perhaps this has something to do with cygwin pathing issues? The Cargo is a windows 64 bit build. Which I suspect means that Cargo is taking the cygwin PATH of /cygdrive/c/cygwin64/usr/share/git-core/templates/ and trying to access it, which would not be possible through a windows executable. My git is not a windows based git, is supplied from Cygwin's git. which git returns /usr/bin/git.

It can be fixed by utilising something like cygpath in order to convert unix style paths into windows style paths:

 ± cygpath -w `git config --get init.templatedir`
C:\cygwin64\usr\share\git-core\templates

But of course you don't want to use cygpath executable. Perhaps in the Windows version of Cargo you can detect whether the path looks like a cygwin style PATH, and convert it directly. All Cygwin paths always start with /cygdrive/.

Cargo version: cargo 0.0.1-pre-nightly (9404539 2015-02-09 20:54:26 +0000)

[CMCDragonkai]

It seems to fail even when I try to explicitly change the init.templatedir on the local git config.

I was using git config --local init.templatedir C:\cygwin64\usr\share\git-core\templates

Which changed the local config to point to the windows style path. But running cargo build still resulted in the same error.

[CMCDragonkai]

Also tried setting the $GIT_TEMPLATE_DIR environment variable to a windows compatible path. I have set it on both Windows native environment variables and Cygwin environment variables, the libgit2 in Cargo doesn't seem to look up the $GIT_TEMPLATE_DIR.

See: http://git-scm.com/docs/git-init#_template_directory The environment variable should have higher precedence than any configuration.

[CMCDragonkai]

Fixed this by doing a global git config:

git config --global init.templatedir C:/cygwin64/usr/share/git-core/templates

So therefore my conclusions are, why is Cargo's libgit2 not respecting --local config nor is it respecting the $GIT_TEMPLATE_DIR (neither Windows native environment variables nor Cygwin environment variables)?

[alexcrichton]

I think that dealing with cygwin-related paths and such is not necessarily under Cargo's or libgit2's purview. I think that you'll get much more mileage just using windows paths everywhere unless you know for a fact that the tool is controlled by cygwin.

For dealing with GIT_TEMPLATE_DIR you may also want to open up an issue against libgit2 as that's probably the best place to handle it (they handle other env vars in other places at least). The --local issue may be our fault, can you elaborate more on that? (e.g. what the expected behavior is and what was actually found)

[CMCDragonkai]

I put an issue on libgit2 libgit2/libgit2#2910

With regards to the --local issue.

Basically if I run:

git config --global init.templatedir C:/cygwin64/usr/share/git-core/templates

Cargo build works.

If I run instead:

git config --local init.templatedir C:/cygwin64/usr/share/git-core/templates

Cargo build doesn't work.

This means Cargo build's libgit2 is not taking into account the locally configured path only the global path. There's also a thing called --system path, but I have not tried that.

The git template directory according to the git documentation says that it should be queried in this order: GIT_TEMPLATE_DIR, local config, global config, system config, default path.

[alexcrichton]

So the behavior you're looking for is that the local init.templatedir will affect the global checkouts of git dependencies?

[CMCDragonkai]

I see what you mean, I was unaware of git clone being considered a global command. It's just that it kind of makes sense if you start a repo, change the init.templatedir for that current repo, and then run git clone or whatever libgit2 is doing in order to bring in dependencies for that particular project's repo. Otherwise, what's the point of having a local init.templatedir then?

[alexcrichton]

Ah what I mean is that the checkout of git repositories is a global operation because all Cargo projects share the same cache for git dependencies. I would expect a clone of a submodule, for example, to use the local init.templatedir but not the global "check out this dependency" operation.

[CMCDragonkai]

Ok, so we are in agreement that the local init.templatedir should be used right? Anyway the guy from libgit2 answered: libgit2/libgit2#2910 (comment)

He said libgit2 doesn't check environment variables. But can be passed configuration paths. Perhaps this means cargo should be checking them and passing the correct configuration path? (Specifically the local init.templatedir).

[alexcrichton]

I think I may not quite yet grapple what init.templatedir should be used for here, so maybe it would help to draft up a patch? If you're missing any options in git2-rs please let me know!