reddit / emacs
Using Java lsp in a Git repository with existing Eclipse project files
hardwork179 · 2022-10-18 13:47
I need to do some work on a large repository which already contains a large number of eclipse project files. They apparently can't be removed, and they are a real pain when I try to use lsp java as it updates many of them and creates a lot of new ones.
No problem, I thought, I'll just create a parallel directory structure and symlink things in places, and then import that into lsp. However, at some point in the process of importing the project (based on Maven pom files) it canonicalises some paths and ends up importing the original directory structure.
I realise this is more of an underlying Eclipse issue, rather than an Emacs one, but does anybody have a good suggestion for how to work round this?
MrTinyToes · 2022-10-18 15:42
If I'm understanding correctly, do you just need a gitignore?
https://github.com/github/gitignore/blob/main/Global/Eclipse.gitignore
hardwork179 · 2022-10-18 16:03
No, a .gitignore would be trivial, and honestly even a large number of untracked files wouldn't be much of an issue. The problem is that there are *already* `.project`, `.classpath`, and `.factorypath` files in the repository, and `.settings` directories, and the lsp server (a headless version of Eclipse) will alter those files. A `.gitignore` file won't make Git ignore changes to files it is already tracking.
I cannot simply get rid of those existing files from the git repository, so I really would like a way to use lsp mode that won't touch them.
Imaltont · 2022-10-18 16:50
[Maybe you're looking for something like this](https://git-scm.com/docs/git-filter-branch). Read documentation carefully and/or use that other tool they link to before doing anything, or have lots of backups in case things go wrong.
Edit:
For future projects, it would also be possible to set a global gitignore that just ignores all the auto-generated stuff you know your text editor or LSP will generate, so you don't have to set it explicitly in all projects, and still removes the chance of it being accidentally committed. Also imo keeps it cleaner with only having project specific artifacts ignored in the project's gitignore, while your personal editor things is kept to itself.
jplindstrom · 2022-10-18 17:01
I think this might be useful to you:
https://wildlyinaccurate.com/git-ignore-changes-in-already-tracked-files/
Helped me out the other day.
LinkHimself · 2022-10-18 17:40
I'm curious, why are there tracked files for eclipse? And why do they have to be there?
hardwork179 · 2022-10-18 18:45
Historical reasons, and some tooling used by other teams. In a sense the reasons don’t matter, if you are working with other people there will always be things that seem strange or could be done better, but it will take some political effort to change stuff. Even though I might think that things like project files should always be either user generated or a build artefact, I may not want to spend political effort and capital changing the course of a large established organisation.
hardwork179 · 2022-10-18 18:48
Thanks, that looks like it might well help.
LinkHimself · 2022-10-18 20:13
I can totally relate to that sentiment.
MrTinyToes · 2022-10-18 20:16
https://stackoverflow.com/a/39776107
Here's what I've used in the past to ignore future changes to already tracked files. It is a more modern solution and longer lasting than `--assume-unchanged`
phylixer · 2022-10-18 21:31
In what way do these files get altered? Lsp IS eclipse jdt running, it is eclipse so maybe the changes are not bad and might even be idempotent?
hardwork179 · 2022-10-19 11:47
It's mostly updating things like java source version, xml formatting, and other fairly trivial things. These types of changes aren't bad, and would be fine most of the time, but are a real pain when they recur during an operation like rebasing.
/u/jplindstrom's solution of telling git that those files are definitely up to date, and it shouldn't even check them, seems to work so I'm going with that, along with ensure all future such files are ignored.
Interestingly several subdirectories within the repository already have `.gitignore` files, so there has clearly been a previous attempt to minimise the annoyance.