Make target dir self-ignoring

[senekor]

Problem

Every Rust project using git requires a .gitignore file with the content /target. This contributes to a cluttered project directory.

Proposed Solution

Whenever cargo creates the target directory, it should also create a file target/.gitignore with the content * to ensure the directory ignores itself. That way, a top-level .gitignore file that's checked into version control can be avoided completely in many cases.

Notes

This is part of #11548, which also proposes that cargo doesn't generate the top-level .gitignore file anymore. As mentioned in this comment, that should only be done much later (if at all) for backwards-compatibility reasons.

[epage]

If this is something we always write out, how do we decide which tools that we make it self-ignoring for?

A lot of this was talked about in #11548 but now we're splitting that conversation. If we split it, its important to collect context like that.

That way, a top-level .gitignore file that's checked into version control can be avoided completely in many cases.

How often do projects only have target in their gitignore?

[senekor]

how do we decide which tools that we make it self-ignoring for?

Do you mean which VCS? Judging from their documentation, mercurial, fossil and pijul don't support this kind of approach. (I haven't verified it though, I don't know / use any of them. Their documentation might just be incomplete.) So, I'd say only git (and because of its git-compatibility, jj).

If the other VCS gain support for self-ignoring directories, I don't see a reason not to support it from cargo's side.

How often do projects only have target in their gitignore?

I don't have the numbers. Do you think this is not worth it because most projects need a gitignore anyway?

I realize this proposal isn't a ground-breaking value-add, but I don't see much of a cost to it either.

[epage]

I realize this proposal isn't a ground-breaking value-add, but I don't see much of a cost to it either.

• its adding an inconsistency that we have to keep in mind and deal with
• There is nuance to how/when to write the file to target/ to make sure we get behavior we want for people to rely on

Neither of these is necessarily a deal breaker but when it comes to allocating my focus, I want to understand "is this worth it".

[weihanglo]

Probably this scenario: if you set build.target-dir to some path else that is not git-ignored. With this feature it is still ignored without any further user intervention.

[senekor]

Code complexity is a valid cost to consider. I don't think there is much benefit beyond avoiding a (relatively harmless) file for small repos.

Probably this scenario: if you set build.target-dir to some path else that is not git-ignored. With this feature it is still ignored without any further user intervention.

While that's true, I'm guessing most people who configure their target dir put it in a completely different place than their repo anyway, right?. Otherwise, what's the point? (I imagine ~/.cache, /tmp etc. are reasonable candidates.)

[senekor]

So is the conclusion here "not worth the additional code complexity"? In that case, I would close the PR and recommend the two issues be closed as well.

[weihanglo]

If I understand correctly, Ed is more on "not worth shifting his focus to explore" (which he really has a long open source backlog), but not "not worth for the code complexity added.". The latter one is left for someone interested to explore. Granted, Cargo maintainers still need to spend time on thinking edge cases even someone has done it.

[epage]

I think my comment was both (1) is this worth my time to help lead and (2) is this worth my team to be a part of decision making / dealing with yet another corner case in maintaining.

However, my voice is mine alone and other team members can have their own opinions and we can discuss and come to a conclusion on what we are willing to accept.

Something else to keep in mind is that we have plans for evolving the target where we split it in two, move one part out of the users directory, and allow users to templatize the location for both parts. I expect this to reduce the need to even set --target-dir to another location within a git repo unless under specific circumstances where gitignoring is unlikely to be happening (using --artifact-dir as part of a release process).