Skip to content

Cargo init does not respect git config default branch variable #8588

Closed

Description

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-gitArea: anything dealing with gitC-bugCategory: bugCommand-initCommand-newS-blocked-externalStatus: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions