IntelliJ Is acting terribly wierdly under this scenario


We have a huge application where we do all our development in IntelliJ. One main folder in this big application is called installation-media-maker. In here we do a lot, such as:

  • creating NSIS installers.
  • creating .exe launchers.
  • creating custom reduced JRE distributions.
  • creating compressed datasets and assets.
  • creating a compressed, obfuscated, reduced and customized distribution of our main bulk code base. This is accomplished by having a staging folder in here and checking out via git from our stagging and/or production git repo. Thus, we sort of have a git within a git and the command we run is either
git clone --depth 1 %REPO_URL%


git pull --depth 1 --allow-unrelated-histories %REPO_URL%

After we have all these "pieces" built discretely, we then have a process that assembles all these pieces, zips them, creates checksums, uploads to our download site, etc... for a variety of distributions that are OS, processor architecture and client specific.

I think the root of my problems is this git within a git, the symptoms are as follows and are absolutely killing me... please help:

  • When I change 5 files and only push 2 of them (via normal intelliJ push), the other 3 files are reverted to whatever the repo has and my changes are lost.
  • When I look at local history, it appears that many files have the local history lost.
  • When I look at local history, I usually see a line that says "external change" and that seems to be where my changes were overwritten.
  • When I pull from our main developers repo, it appears to update the stagging area for our app even though this area is excluded and ignored. Sometimes it seems changes are undone by this as well.
  • I see "Performing VCS refresh" way to often. It takes a little while, but not as long as it took before I excluded and ignored all the stagging areas.



Comment actions Permalink

So today I spent 5 hours coding, then I committed using IntelliJ's green check button. No problems. Then I pushed by right clicking on project explorer, then git, then repository, then push... as I usually do; at this point, it appears that a local rebase occurred undoing all my changes for the lasta 5 hours and nothing was pushed.

I then spent the next hour trying to get all my work back and I seem to have. After that, I deleted all these various staging areas, committed and pushed without issue... so I'm certain the stagging areas are causing the problem even though they are excluded and ignored. I believe the root of the issue is that many of these stagging areas have their own .git folder, and that gets duplicated and moved around to multiple staging areas... bottom line by the time everything is said and done I have like 9 git folders w/ duplicates spread out all over the place.

So, I think the solution is to delete the .git folders once an area is staged and before I move any of these staged files to another area.

Can anyone confirm? Is there a better appreoach before I implement?

Comment actions Permalink

IntelliJ works only with those git repositories that are registered in Settings | Version Control. By default, all git repos found within the project are registered.

If you have repositories in the project that you do not care about, go to Settings | Version Control and remove unnecessary mappings. Note that IDe will not re-register repos at the same path, but if later the path changes, the repo will be registered again.

The description doe not make it 100% clear what exactly happens and why. Rebase can happen after push only if push gets rejected, and you have the Automatically update after rejected push option enabled in settings. But this should definitely not delete any work. Uncommitted changes get stashed before rebase though, so probably the issue is that they get stashed (in the Local history it will be external revert indeed) and not unstashed later for some reasons.

But it is hard to tell without the logs. So if the issue happens again, please:

* Check if changes are stashed

* Submit an issue to with logs attached


Please sign in to leave a comment.