Closed ssokolow closed 7 years ago
cc @ehiggs @gchp
If I understand correctly, your template has a .gitignore
but it wasn't used by cargo new
and some other .gitignore
was generated. And the expected behaviour is that it should use the .gitignore
from your template verbatim. Makes sense to me.
Yes, that's correct.
The template contains a .gitignore
which ignores the target
folder and the temporary file used by my justfile
for passing profiles from callgrind to kcachegrind.
cargo new
instead populates new projects with a .gitignore
which ignores target
, *.rs.bk
, and Cargo.lock
. (The latter being a problem because not all templates are going to be --lib
templates.)
Yeah makes sense to me as well to use the .gitignore
from templates over the built-in one, thanks for the report @ssokolow!
Templates have been removed pending an RFC. There is a pre-RFC thread here. I think this can be closed for now.
Thanks @ehiggs!
While investigating another flaw in
--template
, I discovered the following undesired behaviour when generating a test project from my boilerplate for CLI utilities:While I admit I forgot to exclude *.rs.bk, the rest is unhelpful.
What's worse is that I don't see how this actually helps anything, given that, for a project template, there isn't really much of a purpose to
.gitignore
outside of being passed on to the generated projects. (It's not as if the template'sCargo.toml
is valid TOML before the placeholder for the author list gets substituted.)You'll also notice that it's adding
Cargo.lock
to the.gitignore
when this is specifically intended as--bin
project template, not a--lib
one, so that's not helpful either.I think a proper solution would be to only generate a .gitignore if none is present in the template
As-is, I'm forced to go back to what I used before... a wrapper script.