cargo new can generate a better .gitignore file

[deepak]

running cargo new hello_world --bin --vcs git

generates a .gitignore file with

target

can we use something like https://github.com/github/gitignore/blob/master/Rust.gitignore ?

am using "cargo 0.9.0 (8fc3fd8 2016-02-29)" on OSX

[steveklabnik]

This wouldn't be any different, all compiled files are in target?

Plus, it will add the .lock file if you leave off --bin.

On Wed, Apr 13, 2016 at 3:48 AM, Deepak Kannan [email protected]
wrote:

running cargo new hello_world --bin --vcs git

generates a .gitignore file with

target

can we use something like
https://github.com/github/gitignore/blob/master/Rust.gitignore ?

am using "cargo 0.9.0 (8fc3fd8
8fc3fd8
2016-02-29)" on OSX

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#2565

[deepak]

@steveklabnik ah ok. was not aware

Do you think it makes sense to change the generated .gitignore file to ?

# Generated by Cargo
/target/

# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
# More information here http://doc.crates.io/guide.html#cargotoml-vs-cargolock
# Cargo.lock

I should have mentioned before,
that I am a rust noob. am trying out rust for the first time.

Generally I always look at the github/gitignore repo
for a "standard" .gitignore file
hence this issue

[steveklabnik]

apparently github also ate the second half of my reply, due to mail

but it also will put the Cargo.lock in or not based on if you pass --bin or not.

I would rather submit a PR to the gitignore project to fix it to be more like ours, personally. @alexcrichton what do you think?

[alexcrichton]

Yeah I agree with @steveklabnik that these entries are at least not necessary:

# Compiled files
*.o
*.so
*.rlib
*.dll

# Executables
*.exe

(as they're all in the target directory). I also don't think the leading / on target is always wanted because you may have sub-projects in Cargo which have their own target directories. It's relatively rare to name a module target so those projects can always tweak the gitignore specially.

As for Cargo.lock, I like having documentation in .gitignore, but @steveklabnik is also right that we generate it appropriately based on whether we're a library or binary, so for a "one true gitignore" it should be fine to leave in with docs + a link (as it is now), but through Cargo we already take care of it.

So I guess, yes, I agree that we should probably send a PR to gitignore to remove the build artifacts, but otherwise seems like a good gitignore to me!

[alexcrichton]

Closing as we probably don't need to make changes locally for now, but thanks for the report!