Create .gitignore even if inside existing repository

[vbrandl]

Describe the problem you are trying to solve

When creating a new cargo project using the cargo new subcommand inside an existing git repository, cargo does not create a .gitignore file. That way, also the target directory will be tracked by git.

See also #9633

Describe the solution you'd like

Even if a new project is created inside another git repository, the .gitignore file should still be created

[dsolisherrera]

Implementing the described solution would be really nice, I just ran into the same issue.

[Iniesta8]

@alexcrichton: What do you think about adding target instead of /target to .gitignore or ignore files of other VCS?

If you do so, subprojects would also be covered by the existing ignore file.

Another approach would be to propagate existing vcs ignore files (see my pull request).

[Flying-Toast]

Instead of defaulting to not creating .gitignore in these situations, cargo should give the option to opt out of creating it by passing cargo new an option such as --workspace-member or --in-workspace. IMO, this would be more correct since there are no circumstances where build artifacts should actually be tracked in VCS.

[agorgl]

Any progress on this?

[ehuss]

The cargo team discussed this today, but didn't have a specific conclusion. Some notes:

• Related issue #11548 proposes to put .gitignore inside of target instead of at the package root.
• Related issue #15061 is a variant of #11548 that suggests doing both the current behavior and the target directory.
• Those solutions have some similar concerns about problems we have with ignoring target for backups, that is if the directory is created by another tool, or cargo itself does things incorrectly. It's not clear what cargo's behavior should be in that case.
• Those solutions also have questions around how it interacts with non-git VCS tools.
• I wonder if the landscape has changed now that we have #12779 where cargo new automatically adds to a workspace. Previously, cargo didn't know if something was going to be a part of a workspace or not, and thus didn't know if the .gitignore would be relevant. That is in part the reason why cargo new didn't do anything inside a pre-existing git repository.
• There were some concerns about the amount of flexibility and logic cargo new should have.

For now I'm going to mark this as needs-design since there is a bit design space to consider and it isn't clear what cargo should be doing, especially around all the edge cases, and how much complexity we want to accept.