Cargo new does not follow "includeIf" in .gitconfig

[justfortherec]

This is a trivial bug: The name and/or email address of the user may not be set correctly by cargo new.

Problem

cargo new sets the user name and email in the Cargo.toml file based on the values configured for Git. Since version 2.13, .gitconfig can include other configuration files based on the prefix of the repository. I use this to set separate email addresses for private and work projects based on where a repository is located in my file system. See this Stackoverflow answer for details.

Unfortunately, Cargo (version 1.48.0 (65cbdd2dc 2020-10-14)) seems to ignore these include directives.

Steps

1. Add an includeIf directive to the global .gitconfig:

$ cat << END >> ~/.gitconfig
[includeIf "gitdir:~/test/"]
    path = ~/test/.gitconfig
END

2. Set the user details in the included file:

$ mkdir ~/test
$ cat << END > ~/test/.gitconfig
[user]
    name = "John Doe"
    email = john@example.com
END

3. Run cargo new in a directory with the prefix of the includeIf:

$ cd ~/test
$ cargo new example-project

Expected outcome:

The generated file ~/test/example-project/Cargo.toml uses the user details from ~/test/.gitconfig:

authors = ["John Doe <john@example.com"]

Actual outcome:

The Cargo.toml file does not include the set user details:

$ grep authors ~/test/example-project/Cargo.toml
authors = ["my-username"]

Possible Solution(s)

Updating whatever is parsing the .gitconfig files might solve the problem.

Notes

Output of cargo version:

$ cargo --version
cargo 1.48.0 (65cbdd2dc 2020-10-14)

[DJMcNab]

My understanding is that this behaviour is correct - the includeIf only applies in a git repository's directory; when you run cargo new you are not in one.
E.g. run git config user.name in your ~/test directory

However, in terms of practicality, it's not ideal. If we're lucky changing

cargo/src/cargo/ops/cargo_new.rs

Line 856 in 9051345

Ok(cwd) => GitRepository::discover(cwd)

to get the config in the new directory would fix this.

[justfortherec]

My understanding is that this behaviour is correct - the includeIf only applies in a git repository's directory; when you run cargo new you are not in one.

Fair enough.

However, in terms of practicality, it's not ideal. If we're lucky changing get_real_git_config() to get the config in the new directory would fix this.

Yes, this seems correct. It is exemplified by the fact that cargo init works as expected, i.e. it picks up the included configuration because the cwd is a Git repository.

How do you think changing get_real_git_config() should work? It is used by both init and new. I see two possible ways:

1. In new change the working directory before invoking mk() or
2. Use the path option instead of using the current working directory.

The second option seems preferable to me (because no implicit global state in form of the current working directory would need to be changed). However, it would require the path as a new parameter for discover_author(), find_git_config(), and find_real_git_config().

Or is there another way that I don't see?

[DJMcNab]

Yeah, passing the parameters down the call stack would be the correct method. Changing the current directory is very fragile.