chore: include Linux and JetBrains specific files in .gitignore

[GresilleSiffle]

I finally took the time to add more files to the .gitignore. The git diff commands should be less talkative now, at last on my laptop.

All sources come from the https://github.com/github/gitignore project.

Concerning JetBrains, as we don't plan for now to share configurations and as we use different IDEs I simply ignored all files specific to JetBrains IDEs.

[sigmike]

Shouldn't these files be ignored by a personal global gitignore?

[GresilleSiffle]

hello @sigmike

Shouldn't these files be ignored by a personal global gitignore?

I'm not familiar with global .gitignore to be honest. Are there reasons that make personal global .gitignore better than a per project configuration?

Having a configuration defined at the root of this repository allows us to not rely on the fact that maybe developers have took the time to define a personal configuration, and makes us sure that no unwanted file will be pushed by mistake.

These options don't seem to be mutual exclusive, developers can still use personal .gitignore in addition to per project ignore file right?

[sigmike]

Are there reasons that make personal global .gitignore better than a per project configuration?

Yes, each contributor has a different environment, and that implies a different set of files to ignore (each editor will have its own form of backup or temporary file, each OS may have different auto generated files, etc.). You can't handle all these contributor specific rules in the project, especially in an open source project. The ignore file would be unmaintainable. The project's .gitignore should only handle files generated by the project itself (node_modules, compiled files, etc.), but the files generated by the contributor's environment should be handled by a personal gitignore.

Of course if many contributors use the same environment you could add them to the project's gitignore. But it's a favor to them and it doesn't encourage good practice.

Having a configuration defined at the root of this repository allows us to not rely on the fact that maybe developers have took the time to define a personal configuration, and makes us sure that no unwanted file will be pushed by mistake.

Sure, but you won't handle all the cases.

Have such files already been pushed in a PR? When that happens I think it would be better to suggest the contributor to setup a personal global gitignore. It's very easy to do (https://sebastiandedeyne.com/setting-up-a-global-gitignore-file/) and will help the contributors in the future because they won't have to add the same rules to all their projects, or change all their project's .gitignore file if they change their environment.

I guess if you often have contributions that include the same files then you could add them to the project's ignore file to avoid having to repeat the same suggestion over and over. But I would wait for that to happen.

These options don't seem to be mutual exclusive, developers can still use personal .gitignore in addition to per project ignore file right?

Absolutely, it's like the 2 files are concatenated when git evaluates untracked files.

[GresilleSiffle]

Thank you for taking the time to answer : )

After reading you I'm now in favor of removing IDEs specific files from the .gitignore. I would be in favor of keeping them if every member of the code team was using the same IDE, but that's not the case.

I'm still in favor of keeping OSs specific files in the .gitignore are OSs are much less diverse than IDEs, and are easier to maintain (the project https://github.com/github/gitignore eases the process a lot).

@sigmike what's your opinion on this proposition:

• having a small .gitignore file containing only Linux and macOS specific files (that are the OSs of the core team)
• (optional) invite contributors in the CONTRIBUTING.md file to set-up a global .gitignore, containing specific IDEs files, just to encourage better development practices?

[sigmike]

I'm not sure you can keep the gitignore small even if you only keep OS specific rules. The macOS one is pretty big already (and has a weird \r that can very easily disappear by just saving the file on many editors). And the Linux one seems weird to me: I use Linux and it only has 2 lines in common with my global gitignore (I don't use KDE or NFS, and never had a .Trash-* file in my projects, and I think the .fuse-hidden* only happened on an encrypted directory).

I think these rules pollute the project's gitignore, but many other projects also have such rules. And since tournesol only has sub projects in subdirectories there's no need for a project level ignore file, so it's not really polluted.

I thought the global gitignore was more well known, so spreading awareness by mentioning it in the documentation is probably good. Or you can wait for the problem to happen (either people adding their rules to the ignore file or pushing unwanted files).