Consider linking to the Cargo.lock FAQ in the .gitignore

[CryZe]

Problem

While I don't think the new change is a good idea, I do like that the pros and cons are documented nicely now. To direct people to this documentation, it would probably make sense to include a link to the documentation in the .gitignore, similar to how Cargo.toml already links to its documentation:

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

Proposed Solution

/target

# Whether Cargo.lock should be checked in or not depends on your project:
# https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control
# /Cargo.lock

Notes

No response

[epage]

First off, I admit I'm biased by my being in favor of 99% of people committing their lockfiles and in that case there is little reason to link to documentation in this context.

For me, a big question for cargo new is what the right balance for boilerplate is, things that the generator puts in that you have to remove. Any boilerplate we add needs to do carry enough weight to justify it. I'm already wishing the existing comment was handled differently (see #12210).

Another element to utility is whether people see it to be able to act on it I tend to not look at my gitignore files and could miss a comment like this. I don't know what that would be like for new users. My guess is they are even more likely to not look there or think about it.

[epage]

Based on this comment

I'm going to move to close this, and defer to #5151. In #6881 the team explicitly decided not to add more boilerplate or content to the default manifest beyond the link to the documentation. I realize discovery and education is difficult, but I think on balance adding a large section that everyone will need to delete has its own downsides. I'm not sure if configurable templates would be the solution, but I think it would be a pre-requisite if we were to decide to make this default to offer a simple way to turn it off.

So I'm going to close this likewise