Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit » EGit says files are dirty but Git says working directory is clean
EGit says files are dirty but Git says working directory is clean [message #990505] Wed, 12 December 2012 19:07 Go to next message
Rich DiCroce is currently offline Rich DiCroceFriend
Messages: 5
Registered: August 2012
Junior Member
I'm at the end of my rope here.

For the last two hours I've been trying to figure out why EGit is telling me that a file is dirty when it is not. Example: I open a text file in the repository. I add something, save, undo, then save again. The file is now back to its original content, but EGit still shows the file as being dirty.

Similarly, I can't successfully discard changes to a dirty file. My understanding is that Replace With -> HEAD Revision is supposed to accomplish this. But whenever I try it, the file is still showing as dirty afterwards. And if I do it on a file that's not dirty, it suddenly becomes dirty.

Meanwhile, if I do git status on the command line (or, more accurately, in Git Bash, since I'm on Windows), it reports that there's nothing to commit and the working directory is clean.

Anyone know WTF is going on here?
Re: EGit says files are dirty but Git says working directory is clean [message #990523 is a reply to message #990505] Wed, 12 December 2012 21:27 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
Presumably what you're seeing are unix v dos linebreak differences. What version of EGit do you have installed, and how are you handling linebreaks in your repository?

Some older versions of JGit don't support core.autocrlf properly, and as far as I know, no versions support .gitattributes yet. But you should be ok with core.auto.crlf in the latest EGit/JGit (currently 2.2.0.201212041527)



[Updated on: Wed, 12 December 2012 21:30]

Report message to a moderator

Re: EGit says files are dirty but Git says working directory is clean [message #990542 is a reply to message #990523] Thu, 13 December 2012 00:26 Go to previous messageGo to next message
Rich DiCroce is currently offline Rich DiCroceFriend
Messages: 5
Registered: August 2012
Junior Member
Thanks for the reply. That was the first thing I thought of. Looked at the files in a text editor, they're always CR+LF before and after I edit them. Was using the latest stable release, tried updating to nightly. Problem is still there. Any other thoughts?
Re: EGit says files are dirty but Git says working directory is clean [message #990639 is a reply to message #990542] Thu, 13 December 2012 14:48 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
How is your repository configured to handle linebreaks? Are you using core.autocrlf or .gitattributes, or some other scheme?

If you're using core.autocrlf you might need to force a full re-checkout of the branch so that the autocrlf stuff has a chance to do its thing properly. You should also try making a entirely new clone with the updated EGit/JGit, if only to see if that behaves better. What value of core.autocrlf are you using and what are your unix/linux co-workers using?

As mentioned previously, If you're using .gitattributes I don't think JGit knows what to do with it. I hope this is added soon, as .gitattributes is a cleaner way to deal with this.

Or you could buy a Mac Smile


Re: EGit says files are dirty but Git says working directory is clean [message #990646 is a reply to message #990639] Thu, 13 December 2012 15:08 Go to previous messageGo to next message
Rich DiCroce is currently offline Rich DiCroceFriend
Messages: 5
Registered: August 2012
Junior Member
Making an entirely new clone seems to do the trick. Thanks!

The entire team I'm on (only 3 people) just switched a couple projects to Git from Mercurial. Wasn't our choice; company politics forced the change. So we're all Git noobs right now. No idea what core.autocrlf is set to, but we're all developing on Windows boxes.
Re: EGit says files are dirty but Git says working directory is clean [message #990655 is a reply to message #990646] Thu, 13 December 2012 15:56 Go to previous messageGo to next message
R Shapiro is currently offline R ShapiroFriend
Messages: 386
Registered: June 2011
Senior Member
core.autocrlf and .gitattributes are different ways in Git of handling platform-specific linebreaks. it's mostly intended for projects in which some developers are in linux or os x and others are in windows. The usual pattern is that the internal representation for a linebreak is lf. In windows, lf is converted to cr+lf on checkout and converted back to lf on commit. In linux and os x, lf is left as is. This allows the local representation of text files to have the right form for the local platform, regardless of the internal representation.

core.autorcrlf is a configuration setting that was the original fix for this issue. Each developer has to set this independently. Typically windows users would set it to 'true' (ie, always convert on both checkout and commit) and linux/os x users would set it to 'input' (leave as is, except convert any stray cr+lf to lf on checkout so that it can be fixed).

.gitattributes is a newer and more general approach to this problem. This a file that can be checked in as part of the repository. It specifies the handling of linebreaks, among other things.

If everyone on your team is using Windows and if none of you are making any use of core.autocrlf (or .gitattributes) I'm not sure why you had a problem in the first place. Depending how you set up your local installation of Git, it might well have set core.autocrlf to 'true' at the system level. If the installation prompted you with a question about linebreak conversion and you answered 'yes', that's what happened. If any team member has this setting enabled, all of you have to have it enabled. You can check by running 'git config -l' in the shell or by looking at the 'Properties' view in the 'Git Repository Exploring' perspective in Eclipse.

Mercurial is a clean and elegant distributed version-control system. I used it happily for awhile and was annoyed by the seemingly excessive complexity of Git. But once I grasped a few key Git concepts, it revolutionized my thinking about version control. I'll never voluntarily go back to HG at this point, much less SVN <shudder>.
Re: EGit says files are dirty but Git says working directory is clean [message #991384 is a reply to message #990505] Tue, 18 December 2012 20:32 Go to previous message
Robin Rosenberg is currently offline Robin RosenbergFriend
Messages: 332
Registered: July 2009
Senior Member
Rich DiCroce skrev 2012-12-12 20.07:
> I'm at the end of my rope here.
>
> For the last two hours I've been trying to figure out why EGit is telling me that a file is dirty when it is not. Example: I open a text file in the repository. I add
> something, save, undo, then save again. The file is now back to its original content, but EGit still shows the file as being dirty.
>
> Similarly, I can't successfully discard changes to a dirty file. My understanding is that Replace With -> HEAD Revision is supposed to accomplish this. But whenever I try
> it, the file is still showing as dirty afterwards. And if I do it on a file that's not dirty, it suddenly becomes dirty.
>
> Meanwhile, if I do git status on the command line (or, more accurately, in Git Bash, since I'm on Windows), it reports that there's nothing to commit and the working
> directory is clean.
>
> Anyone know WTF is going on here?

No, but I fixed a bug recently that resulted in reports of false conflicts when switching
branches. The bug was in one of the core classes so might have strange behavior in many
places. The fix is in the nightly builds so you may want to try it.

-- robin
Previous Topic:How to use Egit by code
Next Topic:Egit library ( get repository name by project)
Goto Forum:
  


Current Time: Thu Nov 27 20:10:46 GMT 2014

Powered by FUDForum. Page generated in 0.01797 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software