-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
The current .gitignore lists many files I don't recognize, and I work on this product. That's odd. It's because it's not our .gitignore. We should develop a much shorter one. I don't have a concrete problem to share, however, I have this nagging feeling that these giant .gitignore files will eventually present a supply chain challenge. In general, developers should understand the files they are responsible for. I don't understand the implications of adding or removing most of the lines in this file. That's a bad state of affairs for a file that we're distributing and encouraging users to add to source control that fundamentally changes the behavior of source control.
At the very least, it's not helping people learn about our platform.
Case-in-point:
$ dotnet new gitignore
The template "dotnet gitignore file" was created successfully.
$ wc -l .gitignore
482 .gitignoreThis is the Rust experience. It is comical in comparison.
$ cargo new foo
Created binary (application) `foo` package
$ cd foo
$ ls -ah
. .. Cargo.toml .git .gitignore src
$ cat .gitignore
/targetI also like how cargo does this by default. Doesn't do this if run in a repo.
We should have a command that updates .gitignore to respect artifacts output.