| Egit can't revert commit because local changes to .classpath [message #1798115] |
Mon, 12 November 2018 18:26  |
 Bob Busby
Messages: 2
Registered: November 2018 |
Junior Member |
|
|
A team member converted our shared project from java 1.7 to java 1.8. For some reason, when I pulled the master, I did not get his .classpath or .settings changes, just his code changes, and a lot of stuff wouldn't compile.
I created a branch, then modified the build path and project facet so that things would compile again. I added some changes, committed and pushed. So far so good.
Then a few days later I checked out the master and did a pull and found myself back in a java 1.7 compiler environment with a bunch of files that wouldn't compile. Here I made my fatal mistake. Instead of just merging my new branch, I decided to "fix it". I modified the build path and project facet and etc. Then committed and pushed to the master. (ugh, I should never do that)
Then I tried to merge my new branch again and all my changes got flagged as conflicts. So now I want to just revert the last commit to my master branch, go back to that one (with all the compiler errors) and merge my new branch in (which presumably will contain the .classpath and .settings needed to get back to my java 1.8 compiler).
But when I try to revert the commit, eclipse tells me I can't because of "local changes to .classpath". In desperation, I did an "overwrite" of .classpath to bring in the old changes, but I still can't revert my last commit.
I'm not sure what to do next. Any ideas?
|
|
|
|
| Re: Egit can't revert commit because local changes to .classpath [message #1798624 is a reply to message #1798292] |
Wed, 21 November 2018 09:40  |
Thomas Wolf
Messages: 576
Registered: August 2016 |
Senior Member |
|
|
David M. Karr wrote on Thu, 15 November 2018 02:50I'm pretty sure it's a big mistake to check in the .classpath file...
That advice is definitely wrong. It'd be a big mistake not to check in the .classpath file. (Or the build files like manifests, poms, and so on.)
For other IDE specific files and directories like .project, .idea, .settings, and so on, opinions differ, but I think it's generally a good idea to check those in, too. Otherwise someone cloning the repo will not get the IDE setup. If you want some consistency, you'd want all committers use consistent formatting, style checking, and static analysis settings, otherwise your repo ends up in a mess.
As to the OP's question: sorry, but from that description I cannot tell where the problem might be. Without being able to see what is actually on your computer it's nigh impossible to figure out what is going on. I should hope there is somebody in your team with enough git experience to help you straighten out your problems interactively.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03276 seconds
] 
Search
Help
Register
Login
Home
