Cargo init does not respect git config default branch variable

[Wtoll]

Introduction

This issue affects the most recent version of cargo pulled from rustup: version 1.45.1 commit f242df6. I tried to look through the issues page to see if this has been fixed since, and also the commit history but I didn't see anything to do with this specific issue. If it has already been dealt with I apologize for the unnecessary issue.

The problem

In an effort to try and minimize the use of racially insensitive language, as of Git version 2.28.0 there is now the option to set a git config variable (init.defaultBranch) to rename the default branch generated when using git init to something other than "master." Despite this change, using cargo init still generates the git repository using the default branch "master" regardless of the git config variable.

Some more specifics

If git init is called and then cargo init is called afterwards, git init will create a git repository with the default branch being defined according to init.defaultBranch, and cargo init will not overwrite that. This ends with the branch being equal to init.defaultBranch as it is intended.

If cargo init is called by itself without a git repository already initialized it will create a git repository with the default branch always being "master." This ends with the branch being "master" which is unintended functionality.

If cargo init is called and then git init is called afterwards, cargo init will create a git repository with the default branch always being "master," and git init will not overwrite that. This ends with the branch being "master" which is unintended functionality (unintended in the sense that as a whole the proper branch name is not used. I expected git init to not overwrite the repository created by cargo init, so this is not a surprise).

My opinion

To me it seems pretty reasonable that cargo should follow the git config init.defaultBranch variable when creating the git repository for a new project. I know the rust community is actively working on moving away from racially insensitive language as a whole, but obviously that takes time. That being said, this change seems like a fairly minor stepping stone change that would be pretty easy to quickly implement, but would allow people to start new projects off on the right foot.

It might seem kind of stupid because it's really easy to simply switch branches before the initial commit, but because of cargo's ability to quickly and easily spin up projects, it's often that I forget my branch name is not correct despite setting the git config variable.

Needless to say this isn't an urgent change, but it seems like a really easy one to make that would be both a step in the right direction to minimizing racially insensitive language, and fixing cargo so it doesn't violate intended git functionality.

[Wtoll]

I also just tested on version 1.47.0-nightly (commit aa68721) and I can confirm the bug still persists.

[Eh2406]

We do want this to be fixed, but there's only so much we can do. I believe this is waiting on support in libgit2.

…

On Tue, Aug 4, 2020, 9:05 PM Will Toll ***@***.***> wrote: I also just tested on version 1.47.0-nightly (commit aa68721 <aa68721>) and I can confirm the bug still persists. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8588 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JUQBAAYP2VCWSKHF7E7TR7CV7FANCNFSM4PU563KA> .

[ehuss]

Yea, this is blocked on libgit2/libgit2#5581.

[ghost]

I though cargo just runs git init in the root folder.

[sfackler]

It does not - it uses libgit2 which is not the same thing as git-the-cli-program.

[pyropeter]

libgit2/libgit2#5581 was merged, so this is fixed, right?

[de-vri-es]

Not yet, but once rust-lang/git2-rs#627 is merged and released, and the dependency is updated here, it should be fixed :)

[songyang-dev]

I still have this issue on the latest release. I just installed Rust and its toolchain today.

rustc 1.81.0 (eeb90cda1 2024-09-04)
cargo 1.81.0 (2dbb1af80 2024-08-20)

[weihanglo]

@songyang-dev thanks for the report! Note that this is a 4-year-old closed issue. I just checked and it works. If you don't mind providing a minimal reproducible example, please open a new issue. We can figure it out together then.