'cargo new' and .gitignores

[steveklabnik]

Now that we have Cargo.lock, we should take the opportunity to encourage good habits with regards to it and source control.

Basically, what I'm imagining is that cargo new, when making a binary, should not add Cargo.lock to the ignore. And when making a library, should add it to the gitignore.

What'cha think?

[alexcrichton]

This is what I would expect, @wycats?

[wycats]

Agreed fully.

[Earnestly]

Please don't enforce bad practices (such as using .gitignore files) on users without offering a mechanism to opt-out.

Adding files to a .gitignore comes from the idea of blacklists, a.k.a. default-permit and enumerating-badness which are known poor practices in security. A better practice would be to exclude everything via .git/info/exclude (or setting --global core.excludesfile ...) and adding *. Every file you want tracked needs to be added explicitly via add -f.

A better solution would be simply do nothing instead of trying to second guess what a user might want, at least not until it is configurable.

[wycats]

The opt-out is rm .gitignore or not using the generator to begin.

Not sure how defaults in a generator can be considered "forcing" anything on anyone.

[Earnestly]

You're opting to creating junk files which are not related to the tool by default which is not configurable, I really dislike this behaviour and don't really consider it acceptable without it being optional.

It also rubs me the wrong way when others make these choices based on what they believe to be "encouraging good habits" without any justification, merely what appears to be axiomatic to them.

[tomaka]

I have nothing against git, but I don't like the fact that Cargo creates a .gitignore, whatever is in it.
I don't like when two unrelated tools (cargo and git) are tied together.

[alexcrichton]

Note that git is turned off by default and you have to enable it with a --git flag to cargo new