Harden .gitignore

[pulponair]

Story

Contributors are accidentally commiting changes related to their actual development environment (IDE config files, etc). This leads to unnecessary discussions, slow down of PR acceptance etc.

Requirements

• Adjust .gitignore to "deny, allow"

Acceptance Criteria

• Deny, allow is establisched.

[jketterl]

I really don't consider this a features, so I removed the label.

I am not aware that this has been a problem up until now. As a developer, you have plenty of opportunities to review the changes you're about to commit. If you want to have additional IDEs on the ignore list, feel free to add ignores in a PR. You're also completely free to handle this differently in your fork of this repository.

If you're referring to #267 - I don't see how this could have been prevented by gitignore whitelists, the problem there was a branching issue.

[pulponair]

@jketterl jepp i am refering to #267. Actually the contributor is a friend of mine and he ask me about how to do "git stuff" etc. I (hopefully) explained him how to file a PR by the book. But while talking about that i noticed that for someone who is not doing programming all day long it might be a good thing to have some strict basic rules. Don't you agree?

[D0han]

Ignoring IDE specific files should be done probably in user global gitignore config, not in the project specific one.
For reference: https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer

[pulponair]

@D0han you are totally right, but this is not what i am talking about. There is in general two ways of arranging the project .gitignore.

1. Ignore explicit
2. Allow explicit

I am suggesting one should change from option 1 (like it is right now) to option 2.

Reasons:

• It makes life easier because nobody knows what e.g. IDEs/OS/Editor will put which meta files, where in the future
• It makes it easier for contributors to get started
• It keeps the project nice and tidy and well defined

[jketterl]

I must say, I don't have any experience with the whitelist approach for this matter. So far, I have only used gitignore in its (probably original) blacklisting approach, and I've been doing fine most of the time. Yes, I do make mistakes from time to time (everybody does) but I'm not sure how many of these could have been prevented with a whitelist. The good thing about git is that you can always revert / amend / rebase or whatever it takes to undo an error.

I keep my IDE on the blacklist (that's the .idea entry, which probably covers most products by IntelliJ) since it doesn't cause much of a fuss and is pretty unambiguous. Not sure if this applies to other IDEs as well. Personally, I'm not happy with the IDE storing its settings inside the checkout in the first place, but I guess that's a matter of workflow (I hear others actually prefer to commit that directory to sync IDE settings across their team).

As a developer, I do agree that a certain amount of restriction is reasonable. I do however try to keep my restrictions down to the level where they don't interfere with my routine work. If I do need to spend extra time circumventing a restriction on a regular basis, it's probably better to drop the restriction.