cargo-new ignores $GIT_TEMPLATE_DIR

[BenWiederhake]

cargo new also initializes git. Awesome! Git is configurable through environment variables. Awesome! So why does git, when invoked by cargo, suddenly stop listening to its environment?

Steps to reproduce / I tried this:

$ mkdir empty_reference_dir
$ export GIT_TEMPLATE_DIR=$(realpath empty_reference_dir)
$ cargo new newproject

Expected behavior / I expected to see this happen:
Absence of files/dirs .git/description, .git/hooks/, and .git/info/.
Or more generally: I expected the absence of the files usually found in /usr/share/git-core/templates

Actual behavior / Instead, this happened:
It seems like all files from /usr/share/git-core/templates were copied.

My best guess: Either cargo crafts its own "clean" environment (why should it?), or cargo's emulation of git is incomplete.

For reference: A simple git init works as I desire, i.e., it obeys GIT_TEMPLATE_DIR. So at least I'm sure I didn't have a brainfart there.

[alexcrichton]

I think this is similar to #1295 where it was found that libgit2 doesn't read this env var

[BenWiederhake]

You're absolutely right, that's exactly the issue I'm facing here. I'm sorry I haven't looked closely enough.

So libgit2/libgit2#2910 (comment) has been closed, saying that "In general, libgit2 does not take environment variables into account", which is really weird because it breaks mental models and personal configuration.

I can see only three ways to deal with this:

• Send a bunch of patches to the libgit2 developers which adds that functionality, and promise to maintain it. They probably won't accept it anyway. Sigh.
• Change cargo/git-rs/libgit2 so that it obeys "some" git environment flags. That's even more inconsistent than the current situation.
• Accept that it sucks, and put it into the global git config file (git config --global …), and close this issue and Cargo build with dependencies fails on Cygwin referring to git-core/templates #1295 as wont-fix.

Oh well. :/

[alexcrichton]

Oh I'd be fine in the meantime to change the default behavior of git2-rs, it makes sense to me at least to follow what git-the-CLI does by default

[ethomson]

Send a bunch of patches to the libgit2 developers which adds that functionality, and promise to maintain it. They probably won't accept it anyway. Sigh.

As I mentioned over there, no, we likely will not. This is not a bug. Our philosophy is that we are a simple library and there's little way to predict what our users want to do with it. GIT_DIR and GIT_TEMPLATE_DIR and the like are meant to instruct your git client. They are not meant to instruct your dive log, for example, or your package manager.

But I'm not sure why this is a problem; libgit2's defaults are only libgit2's defaults. If you want this behavior in cargo then it should be easy to enable. We would be happy to accept patches that make this experience better and simpler for you, but as mentioned above and in the libgit2 thread - this needs to be explicitly opt in. Please let me know if I can help. 😀

[dwijnand]

I think the next actionable step here is to file this issue against git-rs.

[ethomson]

I think the next actionable step here is to file this issue against git-rs.

👍 libgit2 has added some help here - you can now git_repository_open_with_env to use these environment variables as hints (to behave more like git itself). As I mentioned above, it's still opt-in, but I hope it's much easier and less work to get going.

[alexcrichton]

Thanks for the update @ethomson! @dwijnand agreed that the next step here is adding a binding in git2-rs so Cargo acan opt-in to using that API!

[dwijnand]

Opened an issue in git2-rs: rust-lang/git2-rs#398