Community
Participate
Working Groups
Build Identifier: M20090917-0800 I suspect that packager explorer or navigator do not refresh when a tracked file is modified. A label decoration with the '>' arrow bracket will mark the file as 'dirty' and remain so if you edited the file but undo it to the previous non-changed state and save it. The only way to make the > decoration disappear is if you right click on the file, or the folder it belongs to, and go to Team > Refresh or do 'git status' on the command line. All which are cumbersome. I suggest that this is automatic on each file modification save. Reproducible: Always Steps to Reproduce: 1. Edit file 2. Undo edit 3. Save Now '>' label decoration remains next to the 'dirty but not' file in navigator/package explorer
I can reproduce the following: 1. Edit file 2. Save => dirty marker appears 3. Undo the change made in 1. 4. Save => dirty marker remains 5. Team->refresh => dirty maker disappears Code: DecoratableResourceAdapter@184 if (!timestampMatches(indexEntry, resourceEntry)) dirty = true; dirty marker is set because time stamp of the resource differs from the time stamp in the Git index. Steps 1-5 leave the content of the file unchanged but change the time stamp. Team->refresh seems to update the index time stamp. Conclusion: is this really an error (since there is a change in the time stamp)?
(In reply to comment #1) > Conclusion: is this really an error (since there is a change in the time > stamp)? Does 'git status' show the file?
git status does not show the file.
> Conclusion: is this really an error (since there is a change in the time > stamp)? Checking the change in file content is more important I say, that's where the dirtiness is, not the time.
(In reply to comment #4) > > Conclusion: is this really an error (since there is a change in the time > > stamp)? > Checking the change in file content is more important I say, that's where the > dirtiness is, not the time. Right. But it's the question if this check should be done in a decorator since the check might be too time consuming.
> Right. But it's the question if this check should be done in a decorator That's what the decorator is for right? The label decoration is a source-control specific feature for informing the user on whether the file is 'dirty', which means to me, whether the file has been changed or not regardless of time. SCMs don't care about time right? Or are you asking a technical question? *shrug* Whatever it takes man, just stop the decorator from misleading me into thinking the file is modified when it's not. > since the check might be too time consuming. I suggested doing the check on a save event, which isn't an every second occurrence, plus 'Team -> Refresh' or 'git status' seem to be a speedy enough process. Sounds like a quick fix to me, but I really don't know the technical undertaking.
A fix is proposed at http://egit.eclipse.org/r/#change,1138. Now the dirty marker is determined from the timestamp of the file on disk. If it does not match the content is compared.
Fixed with b50d2355ce2f84c9ce1830b66879859cc70671c0
