IDE files cause continuous problems

[mohrezaei]

The IDE files for Intellij IDEA are not stable. I have to constantly exclude them when committing. Every upgrade of the IDE creates new conflicts (new files, removed files, changed files, rearranged files, etc). On every rebase or other git action (amend, merge, etc), I have to stash them or things go wrong.

Is a one time setup cost really worth the continuous torture?

[bamapookie]

I would suggest adding the recommended ignore entries to your .gitignore file. You can find them here: https://github.com/github/gitignore/blob/master/Global/JetBrains.gitignore

Add that to .gitignore, then run git rm --cached <filename> for each of the ignored files.

[bamapookie]

Also, if you use the .ignore plugin in IntelliJ, that will make the steps above much simpler. You can simply add the template to .gitignore, then restart and it will suggest removing the tracked ignored files.

[nikhilnanivadekar]

@bamapookie would you like to raise a PR to untrack the tracked files and update the .gitignore. Thanks for your pointers!

[bamapookie]

If I can get to it today, I will.

[bamapookie]

@nikhilnanivadekar Question: Do you autoimport your project from maven or gradle? If so, there are additional ignore entries in the template to uncomment.

[mohrezaei]

Here is what git tells me is modified in my source tree:

    modified:   .idea/compiler.xml
    modified:   .idea/encodings.xml
    modified:   .idea/libraries/Maven__org_scala_lang_scala_library_2_11_7.xml
    modified:   .idea/misc.xml
    modified:   .idea/modules.xml
    modified:   eclipse-collections-parent.iml

I'm not sure about .idea/libraries/Maven...: does that match .idea/**/libraries? None of the others would be fixed by the Jetbrain's default .gitignore. If we assume maven auto-import, that would fix modules.xml. That still leaves at least 4 files.

[bamapookie]

@mohrezaei That matches. "**" matches 0 or more subdirectories.

[mohrezaei]

@bamapookie ok, great. What about the other 4?

[bamapookie]

@mohrezaei some config files should remain. If you notice any churn in them (list entries being reordered, for instance), there is an IntelliJ bug to track and fix the reordering here: https://youtrack.jetbrains.com/issue/IDEA-91607. Just comment with the file being reordered and give an example.

[bamapookie]

@mohrezaei If you are using autoimport, there is a commented section that you can uncomment:

# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn.  Uncomment if using
# auto-import.
#.idea/modules.xml
#.idea/*.iml
#.idea/modules

[mohrezaei]

@bamapookie I'd rather not have to create another login on a different tracking system. Here is a branch/commit with these files.

Given that the Intellij issue is 6 years old and the issue appears to be caused by a large number of different causes, I have little hope this can be helped.

@motlin, @nikhilnanivadekar I say we give them 6 months before we give up.

[bamapookie]

@mohrezaei That ticket is actively worked. It is more of an epic, tracking individual instances of churn in files. I looked at your commit above, and it isn't churning, it is just that those settings have changed. Those appear to be valid additions to the files, and should probably be included in a commit.

[nikhilnanivadekar]

@bamapookie if you get a chance, how about we have a PR with the changed settings and ignored files. This is a pain point and I am sure all contributors and maintainers will appreciate it! Thanks in advance!

[mohrezaei]

@bamapookie I'm not sure what you mean by "changed". The only thing I change locally is the name of the JDK.

Some of it is churn (change of ordering), some of it is local stuff I legitimately (and possibly every other user) would not want to commit (e.g. name of jdk), and a lot of it is a mystery (different version of intellij?).

If I commit these, it'll likely cause problems for other people.

I think there is a much bigger issue here. The fact that this super-bug has been around for 6 years is a very clear indication that there is a core structural issue at work.

• The length/complexity of the suggested .gitignore file indicates that JetBrains is not considering version control stability as an important criteria of how these files are created and maintained. If VCS stability was a core criteria, wouldn't it be trivial to move all irrelevant stuff into a single directory and use a one line .gitignore?
• At some level, anything checked into source control should be understandable and reviewable by a human. These files are very far from that. For example, how would anyone know if native2AsciiForPropertiesFiles="false" is right or wrong?
• VCS stability is not something that happens by accident or by fixing dozens of problems that crop up over and over. It's a mind-set that requires a type of discipline. It usually starts with a well thought out specification that would allow, for example, the requisite model/data to be encoded by hand. Encodings that are natively order-agnostic (xml, json, etc) are a bad choice. Forwards and backwards compatibility would be a huge consideration. All the work we, as library developers, put into creating usable API regarding semantic versioning and API evolution would have to applied to the project files. It's not easy, and it's probably not something JetBrains is willing to commit resources to do in the long run.

Just to be clear, I'm not saying Idea is a bad product. It's been my favorite IDE since 2001. It is, however, clear to me that the project files are not a good candidate for version control, especially git.

When I filed this issue, I explicitly did not mention removing the files. Maybe there is a middle ground where we can have template files (e.g. .ideaTemplate directory) and provide a script to copy it over once.

[motlin]

Thanks everyone.

@bamapookie Yes, we configure auto-import. Given that JetBrains themselves recommend ignoring these files, I think we should go ahead with your suggestion. In @mohrezaei's list, this would remove the Scala lib xml, modules.xml, and the iml file. The first two I knew we should probably exclude, but the third is a surprise to me.

That leaves two files which basically just list all the modules. The missing lines are newish modules which have been added; the OSGi bundle and jcstress-tests. These changes should be committed. The only thing this really affects is our TeamCity builds. However, I think it's reasonable to expect we'll change our project files iff the list of modules is changing.

@bamapookie if you have time to help with this it will be greatly appreciated

[bamapookie]

Thanks, @motlin. I wasn't able to get to this since I was leaving for vacation when I first posted.

[mohrezaei]

This is driving me insane. I just wanted to make a simple change to one file, and now I have:

        modified:   .idea/compiler.xml
        modified:   .idea/misc.xml
        modified:   .idea/modules.xml
        modified:   eclipse-collections-code-generator-maven-plugin/eclipse-collections-code-generator-maven-plugin.iml
        modified:   eclipse-collections-code-generator/eclipse-collections-code-generator.iml
        modified:   eclipse-collections-forkjoin/eclipse-collections-forkjoin.iml
        modified:   eclipse-collections-testutils/eclipse-collections-testutils.iml
        modified:   eclipse-collections-testutils/src/main/java/org/eclipse/collections/impl/test/Verify.java
        modified:   jcstress-tests/jcstress-tests.iml
        modified:   jmh-scala-tests/jmh-scala-tests.iml
        modified:   jmh-tests/jmh-tests.iml
        modified:   junit-trait-runner/junit-trait-runner.iml
        modified:   scala-unit-tests/scala-unit-tests.iml
        modified:   serialization-tests/serialization-tests.iml
        modified:   unit-tests-java8/unit-tests-java8.iml
        modified:   unit-tests/unit-tests.iml

It's clear this is never, ever, never, ever, ever, never, never going to be fixed. Can we please get rid of these?

[motlin]

I mentioned in #687 that I'm looking for ways to keep these files checked into version control for TeamCity to read, but not interfere with you if you want to just commit all changes.

I found this command on StackOverflow:

git update-index --skip-worktree <path-name>

It may be worth experimenting with but I'm not totally satisfied with it as an answer because it requires every contributor to run that command.

[mohrezaei]

You probably already know this, but so it's clear in the ticket: the biggest issue these is with our rebase workflow and branching. I have to rollback these if I want to rebase (or switch branches), but typically, I also have to close the ide, because it constantly re-writes these. Then I have to re-do my changes in the ide. I just found out that newer git has this command git stash --include-untracked. I have to try that. Maybe stash/pop is less frustrating.

[motlin]

I don't think I've run into this situation myself but it sounds like the setting rebase.autoStash true might help too. https://git-scm.com/docs/git-config#git-config-rebaseautoStash

On Wed, Jan 9, 2019 at 10:37 AM Mohammad Rezaei [email protected] wrote:

You probably already know this, but so it's clear in the ticket: the biggest issue these is with our rebase workflow and branching. I have to rollback these if I want to rebase (or switch branches), but typically, I also have to close the ide, because it constantly re-writes these. Then I have to re-do my changes in the ide. I just found out that newer git has this command git stash --include-untracked. I have to try that. Maybe stash/pop is less frustrating.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/eclipse-collections/issues/581#issuecomment-452740162, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO6IiPL1bIFj-DW8ovyHj0kR4XYYc9vks5vBgy0gaJpZM4Vex1G .

[mohrezaei]

For pete's sake how long is this issue going to stay open? I just tried to do a simple rebase and git barfed all over my terminal.

$ git rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: Reflection fallback for service loader
Using index info to reconstruct a base tree...
A       .idea/libraries/Maven__org_checkerframework_checker_qual_2_0_0.xml
Falling back to patching base and 3-way merge...
Removing .idea/libraries/Maven__org_codehaus_mojo_animal_sniffer_annotations_1_14.xml
CONFLICT (rename/delete): .idea/libraries/Maven__org_checkerframework_checker_qual_2_0_0.xml deleted in Reflection fallback for service loader and renamed to .idea/libraries/Maven__org_checkerframework_checker_qual_3_12_0.xml in HEAD. Version HEAD of .idea/libraries/Maven__org_checkerframework_checker_qual_3_12_0.xml left in tree.
Removing .idea/libraries/Maven__com_google_j2objc_j2objc_annotations_1_1.xml
Removing .idea/libraries/Maven__com_google_errorprone_error_prone_annotations_2_1_3.xml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 Reflection fallback for service loader
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

I've had it with this nonsense.

[mohrezaei]

This is github's recommended .gitignore for Intellij. It includes the library stuff that failed above. Can we at least use this? Teamcity builds are gone, right? Do we need this stuff at all?

https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore

[josephks]

My IntelliJ deleted these files itself and moved the settings somewhere else, so given that can we delete the remaining files?