New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add *.iml to IntelliJ .gitignore #186

Closed
sanity opened this Issue Mar 10, 2016 · 31 comments

Comments

Projects
None yet
7 participants
@sanity
Copy link

sanity commented Mar 10, 2016

Just experienced an issue because git was messing with various *.iml files. Talked to the IntelliJ guys and they recommended adding *.iml to .gitignore.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Mar 11, 2016

That's doable, and there are two options. One is to add a .patch template to the official intellij template and the second one is to submit this request to GitHub's Official repo.

We can do both with the .patch being a placeholder until GitHub merges any PR's

@joeblau joeblau closed this in b13db93 Mar 19, 2016

@FPar

This comment has been minimized.

Copy link

FPar commented Apr 30, 2016

This commit does not look fine for me, because, at least for me, it causes problems.

I just ran into an issue, where needed .iml files are ignored from my repository. They are referenced within /.idea/modules.xml and when working with modules somebody who imports the project will have to fix all modules by hand if the corresponding .iml files are ignored.

I see two solutions: the first is blocking the /.idea/modules.xml file, but this would mean, that modules are not shared and you have to create all modules by hand again, which can by annoying to do right with multiple modules.
The other one would be, not to ignore *.iml files. This is also recommended by the official documentation: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented May 2, 2016

@FPar Thanks for following up... I can revert this patch when I get home tonight.

@FPar

This comment has been minimized.

Copy link

FPar commented May 3, 2016

Thanks 👍

@ghost

This comment has been minimized.

Copy link

ghost commented May 11, 2016

Maybe we could have a separate setup with excluded idea files? That article says "If you decide to share IDE project files with other developers, follow these guidelines ...", so what if I decide not to do it? For example, If my project is pom-based I shouldn't store any IDE-specific files in version control at all.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented May 11, 2016

If you look at the idea based template, you can also just uncomment the *.iml section.

@volkertb

This comment has been minimized.

Copy link

volkertb commented Sep 23, 2016

@FPar I respectfully disagree with you. For many of us, it is considered a good practice to keep the code repository clean of IDE-specific metadata, any IDE-specific metadata, period. I'm not saying you shouldn't place your project's IDE settings under version control. In fact, it makes a lot of sense to do so, provided you keep it in a separate repository. As a good rule of thumb: if the CI server doesn't need it to build, run, test or deploy the code, then it has no business being part of the code base.

And your claim that including .iml files "is recommended by the official documentation" is simply not true. As @smamontov already pointed out above, the documentation you referred to clearly started with the sentence "If you decide to share IDE project files with other developers...". (Emphasis mine.)

I was surprised and frankly disappointed when I suddenly saw this change after I had checked out a new .gitignore file from gitignore.io. Why does the burden of having to uncomment all that unwanted stuff suddenly have to lie with those of us trying to keep things clean and wanting to follow generally accepted best practices?

Judging from other responses in this issue thread alone, I'm clearly not the only one who disagrees with this change, which seems to have been prematurely made without a proper debate.

@joeblau Asking the developers to revert this change once again is probably too much to ask, but would you then please at least consider adding a parameter called "intellij_all" or something, so that people would have a convenient choice, without having to manually edit their .gitignore files, which would defeat much of the purpose of gitignore.io? That way, as soon as someone starts typing "intellij" in the field, both options will come up, immediately alerting the user that there is in fact a choice. Thank you in advance for considering my request and my apologies for coming off a bit cranky in this response. It's late.

@FPar

This comment has been minimized.

Copy link

FPar commented Sep 23, 2016

@volkertb This issue was never about whether storing IDE specific files generally in a repository or not. For projects within a heterogenous environment I wouldn't check in IDE specific files, too, I totally agree with you in that point.

In the original version IDE files were commited to the repository. In the next version, IDE files were still commited to the repository, but another subset of files. And in the current version they are still commited to repository, the same subset as in the beginning. It's the configuration from github/gitignore.

This particular version was actually a problematic commit, at least for some users, that also didn't agree with the documentation. And this is everything this issue (and my comment) was about. And not about good and bad VCS practices or philosophy this repository should follow.

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 24, 2016

@FPar: I can't follow your argumentation or comment.

Whenever someone decides to use https://www.gitignore.io and deliberately specifies IntelliJ IDEA files as an ignore target, then naturally *.iml should end up in the .gitignore thus produced. In case you do need such files, then comment those lines out. It's as simple as that.

@volkertb

This comment has been minimized.

Copy link

volkertb commented Sep 24, 2016

@FPar Perhaps my initial post indeed came off as a bit condescending, and I meant no offense.

But the fact remains that your requested change inconvenienced a lot of other people. Since you choose to be selective in what IDE metadata you specifically want in version control (which is of course perfectly within your right, don't take me wrong), your workflow is (at least in that one regard) a more complicated and unusual one than that of most other developers in general. That's fine. We all have our specific exceptions and requirements in our own projects. But unique project-specific requirements and exceptions should not be imposed on everyone as the default.

The site is called gitignore for a reason. It's about ignoring stuff. There are labels with obvious names that people choose from, such as "macOS", or "eclipse", or "intellij". People shouldn't reasonably have to expect that some of those labels only selectively ignore things, especially not if the names of those labels do not imply any selectivity. Of course there are obvious cases where things have to be ignored selectively, such as with "maven" or "gradle", since those are build tools. But if I select a label called "intellij" in https://www.gitignore.io, then it should be safe to assume that it means "ignore intellij stuff", not "ignore some intellij stuff and let the users look inside the generated .gitignore file to find out exactly what is and what is not actually ignored".

Also, to quote @sanity in his opening post: "Talked to the IntelliJ guys and they recommended adding *.iml to .gitignore." (Again, emphasis mine.)

@FPar

This comment has been minimized.

Copy link

FPar commented Sep 25, 2016

I would like to review, what happened so far:

  • a86eec4: Behaviour is the same as in github/gitignore and as recommended in the official documentation, ignoring IntelliJ files only partially.
  • b13db93: One user had a (probably) specific problem, suggests ignoring _.iml, but now a project setup, that may be a bit more complex than a default one, but uses common IntelliJ features does not work and the documentation recommends something else, ignoring IntelliJ files only _partially*.
  • 4ba531d: Now the .gitignore is the same, as in the beginning, behaviour is the same as in github/gitignore and as recommended in the official documentation, ignoring IntelliJ files only partially.

I guess, you already noticed, what I want to say here (and what I already said): this is the wrong place for this discussion. This issue was about whether or not ignoring module files in a shared configuration environment. About an implementation detail of the current solution, not about the solution in general.

If you want to propose a general change, what kind of ignore files are provided by gitignore.io, then go ahead, but please don't discuss this in this issue, because it is totally unrelated.

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 25, 2016

@FPar:
Your writing remains hard to follow. Could you please work on it? Perhaps a simpler style would do you more right.

The first link you give points to an apparently unrelated commit to a file.

Your next bullet point claims that github/gitignore excludes *.iml files. I cannot find anything on IntelliJ in github/gitignore, however. Could you please provide evidence?

You then go on to repeat your claim that the IntellJ IDEA docs state that *.iml files should be ignored. @volkertb has made it very clear that is false, and you provide no evidence for that claim either.

Finally you misrepresent the topic of this issue. The topic is clear as day. Let me quote this thread's title:

Add *.iml to IntelliJ .gitignore

This thread is not about your project layout. You fail to demonstrate that your project layout is the default that standard .gitignore files for IntelliJ should account for. Nor is anyone else discussing anything unrelated.

@joeblau: Can you please reconsider your decision? It think it is now clear @FPar's appeal does not have sufficient merit and does not reflect the wishes of the wider community. I propose that you change the commented out patch to a full exclude by default.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 25, 2016

@volkertb or @sanmai-NL - can you please explain the specific problem you're having by having the .iml files in. your project's that you're not sharing?

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 26, 2016

@joeblau: given multiple collaborators who use IntellJ IDEA, their personal settings files clash with the one that sneaked into the repo because of the unexpected exclusion of *.iml files from the default .gitignore.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

@sanmai-NL Based on what you're saying, it seems like IntelliJ's documentation on their site is incorrect. The documentation says:

If you decide to share IDE project files with other developers, follow these guidelines:
...
2. All the .iml module files that can be located in different module directories (applies to IntelliJ IDEA)

But what you and everyone else are saying is that you actually don not want to share the `.iml if you are sharing your project.

@joeblau joeblau reopened this Sep 26, 2016

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

I just sent an email to JetBrains asking for more clarification - when I hear back I'll let you know their response. Thanks for your patience.

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 26, 2016

It does say ‘if’. It's if like ‘if you decide to fix the electrical wiring without a trained electrician, then mind ...’. @sanity reported in his first post that the IntelliJ IDEA team indicated to him that sharing the *.iml files shouldn't be done by default. But you can ask again, that will give you definitive answers.

Including the *.iml files means that your project privileges one particular configuration of the IntelliJ IDE, rather strange for collaborative, professional software projects. An IDE is a personal tool, not e.g. a build system. To avoid that individual developers have to go through a lot of settings initially, IDEs such as IntelliJ IDEA can import software project codebases and find out relevant settings themselves. If this fails, I expect that project to be badly structured.

@kristapsmelderis

This comment has been minimized.

Copy link

kristapsmelderis commented Sep 26, 2016

Code repositories should be IDE agnostic;
I found it bizarre when my .gitignore file suddenly had a patch that ignored entry for *.iml;
I can only agree to @sanmai-NL

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

@sanmai-NL I'm citing your comment in my response to IntelliJ.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

Support Thread:

Josephblau
Sep 26, 11:55 CEST

This page in your documentation is causing some contention between developers and I would like clarification:

https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

Your documentation says to include *.iml files when working with collaborators but most actual developers seem to believe that sharing the *.iml file is actually the opposite of what you want. I maintain https://www.gitignore.io I'm referring to this comment thread.

#186

One comment in particular (#186 (comment)) has 11 up votes from the community asking for the *.iml file to be ignored, therefore not being committed to the repository, and therefore not being shared. My question is whether the documentation is correct or not?

If the documentation is correct, can you provide more details as to why the *.iml needs to be shared so I can document it on my website and also reference GitHub's main project which also doesn't share the *.iml?

Cheers,
Joe


Serge Baranov (IntelliJ)
Sep 26, 14:23 CEST

It would depend on the project. If the project is imported from Maven or Gradle, .iml files are generated automatically and may not be shared, otherwise these files are essential for the project and must be shared so that other users can open the project after checkout.

.iml files contain all the information about the module configuration (the roots, source folders, dependencies, etc).


Josephblau
Sep 26, 17:01 CEST

otherwise these files are essential for the project and must be shared so that other users can open the project after checkout.

A lot of developers online seem to disagree with this assessment. There are multiple resources online which all recommending ignoring the *.iml with no negative side effects to collaborative work. Your customers seem to think that the only information held in there is Local IDE specific information which does not translate to other development environments.

Here is a response from one of the developers in project’s thread: #186 (comment)

Including the *.iml files means that your project privileges one particular configuration of the IntelliJ IDE, rather strange for collaborative, professional software projects. An IDE is a personal tool, not e.g. a build system. To avoid that individual developers have to go through a lot of settings initially, IDEs such as IntelliJ IDEA can import software project codebases and find out relevant settings themselves. If this fails, I expect that project to be badly structured.

There are also many other comments on stack overflow related to Android Studio and IntelliJ in general:

and the list goes on…

Does IntelliJ have the ability to regenerate all of the module configuration (roots, source, dependencies, etc..) metadata?


Serge Baranov (IntelliJ)
Sep 26, 17:08 CEST

Does IntelliJ have the ability to regenerate all of the module configuration (roots, source, dependencies, etc..) metadata?

That is true only for Maven and Gradle projects as I've already mentioned. Android Studio projects are Gradle based, so it makes sense to ignore .iml files for AS projects.

In case the project was created in IDEA and is not Maven or Gradle based, IDEA will not be able to open it without .iml files. User will have to perform all the configuration from scratch. Basic projects can be imported and IDE will suggest source roots and libraries to add, but for the more complex multi-module projects with the dependencies between the modules configuring it from scratch for a new user would be a very hard task and a lot of manual work.

Most open source projects are using Maven or Gradle, so it makes sense to ignore .iml files and not keep them in GitHub repositories.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

After talking to the IntelliJ support team. It seems like all of the problems you guys are experiencing are due to using a Gradle or Maven based project. What I can do is add two new templates.

IntelliJ+Gradle.template and IntelliJ+Maven.template which will properly ignore the *.iml files for Gradle and Maven based projects.

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 26, 2016

@joeblau:
Thanks for making the effort to discuss this issue! It just makes no sense that any project would be intertwined with IntelliJ.

Serge Baranov’s comments appear to me as Java-centric. I did Python projects in IntelliJ, the these do not rely at all on complicated module configurations. There, IntelliJ IDEA recognizes the right ‘facets’ and it's just click-and-play from there on. Also, CMake and other Makefile-like projects I did in JetBrains IDEs do not rely on IDE settings.

I think the crucial part of his response is ...

Basic projects can be imported and IDE will suggest source roots and libraries to add, but for the more complex multi-module projects with the dependencies between the modules configuring it from scratch for a new user would be a very hard task and a lot of manual work

I have never encountered such complex Java projects in which no Maven, Gradle or any other build system was used and the module configuration in IntelliJ IDEA was critical for collaboration. I'm a bit disappointed he pushes that idea.

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 26, 2016

@joeblau: so actually, I'm not using Maven or Gradle a lot and the problem is of a different nature. Having *.iml files in the source tree makes it hard to customize the project’s settings from within a JetBrains IDE without interfering with colleagues’ settings.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

Thanks for making the effort to discuss this issue! It just makes no sense that any project would be intertwined with IntelliJ.

I totally agree - Honestly it feels like a bug in the way IntelliJ manages projects. I don't use that IDE as much anymore, but I would definitely file a bug against them asking them to re-factor how they approach project management with *.iml files.

I'm going to just create an Intellij+iml.gitignore -- hopefully that will be clear enough in the list and I'll also put a link to this thread in the template/

@joeblau joeblau closed this in 2a8c908 Sep 26, 2016

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

@FPar Thanks for your patience with this!

@FPar

This comment has been minimized.

Copy link

FPar commented Sep 26, 2016

I still don't understand, why you all are promoting a solution, which is not IDE agnostic by arguing, that a repository should be IDE agnostic. That's just so schizophrenic.

A .gitignore generated from intellij+iml,java,maven for a project created in IntelliJ by using the maven-archetype-quickstart archetype will still not ignore the files .idea/compiler.xml, .idea/copyright/profiles_settings.xml and .idea/encodings.xml. And with more plugins there may be even more files within the .idea directory. For a repository, which should be IDE agnostic, none of the two fulfils that purpose.

The most accurate solution may be to ignore for /.idea/ and *.iml (plus everything generated at build), but as I said, changing the entire behaviour of the IntelliJ .gitignore should not be in the scope of this issue.

And regarding the "no proof" thing: the only comment, which includes actual proof, in which cases and why you could/should ignore *.iml files, was provided by the IntelliJ guy/@joeblau. Whereas I had a valid reason why you should not ignore them.

I will leave this conversation now, because I don't see any value in participating in it while people are putting words, that I've never said, in my mouth (I'm looking at you @sanmai-NL). The discussion behaviour in this issue is one of the worst, I've ever encountered 👏. Sorry @joeblau for creating so much noise.

@CrazyCoder

This comment has been minimized.

Copy link

CrazyCoder commented Sep 26, 2016

I'm a bit disappointed he pushes that idea.

It's up to the project maintainers to store IDE specific files in the VCS or not, we are not pushing anyone. You are right that most of the complex open source projects already use some build system that can be imported in IDEA (if we are not talking about Java world, I can also add SBT which is supported by IDEA).

In my response I've described the use case when storing IDE specific files in the repository makes sense. One of the examples would be IntelliJ IDEA Community GitHub repository itself.

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 26, 2016

And regarding the "no proof" thing: the only comment, which includes actual proof, in which cases and why you could/should ignore *.iml files, was provided by the IntelliJ guy/@joeblau. Whereas I had a valid reason why you should not ignore them.

@FPar - Actually there is proof from GitHub's main repo... but I didn't want to dig that up.

@CrazyCoder - YOU'RE HERE! Thanks for all of your help as well.

@ghost

This comment has been minimized.

Copy link

ghost commented Sep 26, 2016

Didn't expect my comment will collect so much upvotes, but actually what I meant was, that gitignore.io should provide an alternative template for those who don't want to store IDEA files at all. For Java IDE (Android as well), these are the *.iml, *.ipr, .idea/ (whole dir) and maybe classes/ (which is likely to be created when using Gradle).

Both templates offered by the site is still useless for me... Repeating, what I initially wanted is to have a template which at least exclude:

*.iml
*.ipr
.idea/ # whole directory!

Why I dislike the approach when we're trying to exclude only some files inside .idea/ dir? Because there's no any guarantees that new files containing env-specific configuration won't be created by new IDEA versions. (Or maybe there is a spec tracking all these files?).

PS. And finally, why do new template denies modules.xml in entire repository? File with such a name may really exists in every project...

@joeblau

This comment has been minimized.

Copy link
Owner

joeblau commented Sep 27, 2016

PS. And finally, why do new template denies modules.xml in entire repository? File with such a name may really exists in every project...

If modules.xml is not supposed to be ignored, please submit a PR with the changes you want: https://github.com/joeblau/gitignore.io/blob/master/data/patch/Intellij%2Biml.patch

@sanmai-NL

This comment has been minimized.

Copy link

sanmai-NL commented Sep 27, 2016

@CrazyCoder: You are right I cannot conclude from what you wrote that you're pushing this idea, I've corrected that message.

You describe one particular project layout, one that isn't compelling to most developers here. It shouldn't be the default. You're not claiming it should be, but this is what some others have interpreted.

Repository owner locked and limited conversation to collaborators Sep 27, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.