Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327087

Summary:

Egit 0.9.3 Override a tracked file results in Status "Removed"

Product:

[Technology] EGit

Reporter:

Daniel Stein <daniel.stein>

Component:

Core

Assignee:

Jens Baumgart <jens.baumgart>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

matthias.sohn, stefan.lay

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
first screen	none
second screen	none

Description Daniel Stein

2010-10-06 06:47:37 EDT

Build Identifier: Version: 3.5.1

As shown in the first screenshot(overwriteFileBug1.png) I overwrite a existing tracked jar with another one. If i then wan't to commit the new jar the commit dialog says that the file has been removed (overwriteFileBug2.png). If I then do a git status with the cli, the cli says that the jar file is removed in the Working-Directory and the jar also shows up as untracked file. If I do a git add "xy.jar" with the cli the next call to git status says that the file has been modified in the working directory. After a refresh in Eclipse Egit also says that the file has been modified...

If I replace the jar outside eclipse (Windows-Explorer) (clean git working directory) and do a git status; it tells me that the file has been modified. This is the behavior I would expected...

Reproducible: Always

Comment 1 Daniel Stein

2010-10-06 06:49:50 EDT

Created attachment 180307 [details]
first screen

Comment 2 Daniel Stein

2010-10-06 06:50:10 EDT

Created attachment 180308 [details]
second screen

Comment 3 Stefan Lay

2010-10-06 07:00:35 EDT

This is a result of bug 269067, which has a long history but is unfortunately not fixed. Eclipse sends a delete event when a file is replaced by another one with the same name but not sharing the same local history.

I have currently no good idea how to fix it in EGit only. Maybe somebody else has?

Comment 4 Daniel Stein

2010-10-06 08:11:02 EDT

(In reply to comment #3)
> This is a result of bug 269067, which has a long history but is unfortunately
> not fixed. Eclipse sends a delete event when a file is replaced by another one
> with the same name but not sharing the same local history.
> 
> I have currently no good idea how to fix it in EGit only. Maybe somebody else
> has?

Is it posible to check if the file exists in the git working-directory? 

Eclipse delete Event + file don't exist in working-dir --> file deleted 
Eclipse delete Event + file exists in working-dir --> file modified

I also use subversive. If I overwrite a file in eclipse which is tracked in SVN subversive says that the file has benn modified...

Comment 5 Daniel Stein

2010-10-06 08:17:47 EDT

By the way: 

Even if Egit shows that the file has been removed due to problems with eclipse, Egit must also show the untracked file in the commit dialog, if the checkbox show untracked files is set (second screen).  If it doesn't show the untracked file, one has now chance to commit the modified files in Egit. In this case one is forced to use the cli...

Comment 6 Jens Baumgart

2010-11-08 11:32:43 EST

(In reply to comment #5)
> By the way: 
> 
> Even if Egit shows that the file has been removed due to problems with eclipse,
> Egit must also show the untracked file in the commit dialog, if the checkbox
> show untracked files is set (second screen).  If it doesn't show the untracked
> file, one has now chance to commit the modified files in Egit. In this case one
> is forced to use the cli...

Fix proposed for displaying state [removed, untracked] in commit dialog.
The content of the file in the working directory is committed.

http://egit.eclipse.org/r/#change,1868

Comment 7 Matthias Sohn

2010-11-10 16:42:18 EST

correct handling of state [removed, tracked] merged as 27537e107ba4f07a2fbbe3da28b2fa82ba4f63be

Do you consider this to be a sufficient fix or do you see more room for improvement here ?

Comment 8 Matthias Sohn

2011-01-20 16:50:40 EST

This fix is sufficient to solve this problem