| EGit says files are dirty but Git says working directory is clean [message #990505] |
Wed, 12 December 2012 19:07  |
 Rich DiCroce
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 #990655 is a reply to message #990646] |
Thu, 13 December 2012 15:56  |
R Shapiro
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 |
Robin Rosenberg
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
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04133 seconds
] 
Search
Help
Register
Login
Home
