Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default .gitignore from cargo new should explicitly exclude vendor/ #15352

Open
jyn514 opened this issue Mar 26, 2025 · 1 comment
Open

default .gitignore from cargo new should explicitly exclude vendor/ #15352

jyn514 opened this issue Mar 26, 2025 · 1 comment
Labels
A-vcs Area: general VCS issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-init Command-new Command-vendor S-triage Status: This issue is waiting on initial triage.

Comments

@jyn514
Copy link
Member

jyn514 commented Mar 26, 2025

Problem

cargo vendor creates a bunch of files with paths from other people's crates. people sometimes write poorly specified .gitignore files that are too broad and don't anchor specific directories; this is silly but people do silly things, see for example rust-lang/rust#138978. in this case git add vendor/ doesn't do what they expect, some of the paths are ignored.

Proposed Solution

add !/vendor to the default gitignore.

Notes

i took a look at the code for this. currently the logic lives here:

// Using the push method with multiple arguments ensures that the entries
// for all mutually-incompatible VCS in terms of syntax are in sync.
let mut ignore = IgnoreList::new();
ignore.push("/target", "^target$", "target");

it's not as simple as adding another .push line, because Fossil requires these to be configured in a separate ignore-glob file and Mercurial doesn't support this kind of thing at all. Not sure if this has interactions with pijul.

the current design makes it hard to handle two different files for include and exclude, so that would need to be refactored somehow.

@jyn514 jyn514 added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Mar 26, 2025
@epage
Copy link
Contributor

epage commented Mar 26, 2025

If I understand correctly, the reproduction steps are roughly

  1. Having a Rust project with a .gitignore of target instead of /target
  2. cargo add cc
  3. cargo vendor

To get to Step 1, the user either needed to edit an auto-generated .gitignore, or they hand wrote it.

Changing cargo new wouldn't help with someone hand writing .gitignore. It wouldn't help people already in this situation. It will help someone who runs a newer cargo new and then later needed to hand edit .gitignore to ignore more target directories. That is a limited case but maybe its sufficient.

Its been a while since I've dug into the details of gitignore too much. How might this interact with .gitignores inside of vendor/?

Are there any other downsides to doing this?

people sometimes write poorly specified .gitignore files that are too broad and don't anchor specific directories; this is silly but people do silly things,

Please keep in mind that there may be motivations you do not directly see at this time. For example, I've set my template .gitignore to just target because I've been in enough situations where I've had multiple target directories and it was the simplest way. We even had it this way in the cargo repo until 433635b, likely because we previously didn't have a workspace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-vcs Area: general VCS issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-init Command-new Command-vendor S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants