Community
Participate
Working Groups
Build Identifier: When one deletes a file in Eclipse, EGit does the same as "git rm file". The problem is, there currently is no UI for undoing that operation (getting the file back). On the command line, this is "git reset HEAD file && git checkout file". One can reset the whole repository to get the file back, but that also undoes all the other changes in the repository. Reproducible: Always
In Eclipse CVS this operations is accessible via right click on a folder and then Team -> Restore from Repository... I can imagine a similar action for EGit that brings up a dialog and shows deleted files to restore.
Should this really block bug 293192?
IMO yes, because it makes it necessary to use the CLI to recover from it.
I agree. Restoring locally deleted files is a common use case that should not force people to go the commandline. Other TeamProviders provide this feature via UI, so should EGit.
This is still a problem with 1.0.0.20110526xxxx Furthermore, when we delete a file, you normally expect the parent folder to show that there is a change outstanding. However, this is not shown when a file is deleted - it looks like the parent folder is unchanged. This seems like a serious bug.
I should also point out that none of the tools in Eclipse let you know there even was a deleted file. Compare with Index, Compare with Head show no differences. Only git status from the command line tells you that there was a deleted file.
With http://egit.eclipse.org/r/#change,4647 (Bug364018) applied for one can restore a removed file from the "Staging View" by unstaging the deletion and then "Replace with File in Git Index". For us, this is sufficient.
"Replace with ..." on the nodes parent also works for me.
There seems to be a large overlap between this bug and bug 354982
I tried this with today's nightly build (2011-11-25): > The problem is, there currently is no UI for undoing that operation > (getting the file back). On the command line, this is > "git reset HEAD file && git checkout file". > One can reset the whole repository to get the file back, but that also > undoes all the other changes in the repository. - I tried "Replace with > HEAD revision" on parent folder of resource which has been staged for deletion -> works as expected - also unstaging from staging view works, then do "Replace with file in Git index" from staging view entry -> works as expected - also unstaging from synchronize view works, then do "Overwrite" on the unstaged deletion -> works as expected
Created attachment 210568 [details] stack traces
Please re-open this bug. Just tried nightly build 1.3.0.201202051215 (JGit 1.3.0.201202030851) Deleted a top level folder with a single file. Everything still falls apart when trying to restore it. - Right click on project, Replace With -> HEAD revision An internal error occurred during: "Discard Changes". Empty path not permitted - Team Synchronize -> Overwrite An internal error occurred during: "Overwriting 1 resource.". Attempted to beginRule: P/marctoy, does not match outer scope rule: F/marctoy/src - Git staging view -> "Restore with file in Git Index" An internal error occurred during: "Discard Changes". Checkout conflict with file: src/marctoy.c See attached stack traces file. My old and awkward "stage+checkout" workaround seems to still be the only way.
I think I know why Matthias thought this was fixed: he was only deleting a file while I am deleting a non-empty folder. Now you could be pedantic and ask me to open a new bug "Allow restoring a removed (but uncommitted) FOLDER" instead of re-opening this "file" bug. Please save me time and just re-open this bug. PS: "Right-click *Project* -> replace with -> HEAD" fails with the stack trace I reported even when you have NO changes at all.(In reply to comment #2) > Should this really block bug 293192? God yes. My team mates are turning away from Egit and to Git Extensions because of it.
Being in progress of migrating our company's cvs to git repositories, I also noticed that the behaviour Gunnar mentioned is not available in egit 1.3.0. In cvs projects all deleted files in a folder were listed for restoring, no matter if they were committed or not. The problem is that a "normal" workflow for us is changing,commit,changing,commit,... so a restore from staging area would be no use. How can we get back deleted & committed files without the knowledge of the commit in which they were deleted?
(In reply to comment #13) > I think I know why Matthias thought this was fixed: he was only deleting a file > while I am deleting a non-empty folder. Just opened bug 372133 : Cannot restore deleted (but uncommitted) folder
reopened on Marc's request
(In reply to comment #16) > reopened on Marc's request Thanks, moving the discussion back to this bug since it still has much more information than bug 372133 that I opened in the mean time. Just tried nightly build EGit 2.1.0.201207190713 + JGit 2.1.0.201207172320 and it is a LOT better! Out of the 3 crash + stack traces I reported 2 of them are now fixed. The "Team->Synchronize->Overwrite" STILL CRASHES with the same "does not match outer scope" error and same stack trace. On the other hand the 2 other restorations techniques now work flawlessly. No need for the "checkout" workaround I documented bug 354982. Well done and thanks! Reminder: the problem now happens only when trying to restore file(s) from a deleted (and missing) *DIRECTORY*. PS: at this moment the latest release is 2.0.0.201206130900-r and it does NOT fix any of the 3 methods ("org.eclipse.jgit.api.errors.JGitInternalException: Checkout conflict with file:...") => you need a nightly build to get anything fixed.
For the remaining issue with the Synchronize view, see bug 362219 (currently assigned to platform/team, waiting for a reply).
While verifying this bug with release 2.1.0-201209190230-r I found what seems to actually be a different bug. => "Replace with->HEAD" silently does NOTHING at all when run on a TOP-LEVEL project folder. This different bug is not specific to deleted files: modified files are not restored either! Absolutely nothing happens. The workaround is to "Replace with->HEAD" on every file and subdirectory in the top-level, project folder. I don't remember this behaviour from older versions. Is this different bug already tracked somewhere else?
(In reply to comment #19) > While verifying this bug with release 2.1.0-201209190230-r I found what > seems to actually be a different bug. > > => "Replace with->HEAD" silently does NOTHING at all when run on a TOP-LEVEL > project folder. > > This different bug is not specific to deleted files: modified files are not > restored either! Absolutely nothing happens. The workaround is to "Replace > with->HEAD" on every file and subdirectory in the top-level, project folder. > > I don't remember this behaviour from older versions. > > Is this different bug already tracked somewhere else? When using latest EGit (2.2.0.201210310023) plus latest Eclipse (I20121031-2000) which has the fix for bug 362219, deleted files and folders come back when doing Replace With > HEAD Revision on a project. I'm marking this FIXED. If someone still has scenarios which don't work, then please open new bug reports.
(In reply to comment #19) > While verifying this bug with release 2.1.0-201209190230-r I found what > seems to actually be a different bug. > > => "Replace with->HEAD" silently does NOTHING at all when run on a TOP-LEVEL > project folder. > > This different bug is not specific to deleted files: modified files are not > restored either! Absolutely nothing happens. The workaround is to "Replace > with->HEAD" on every file and subdirectory in the top-level, project folder. > > I don't remember this behaviour from older versions. > > Is this different bug already tracked somewhere else? Yes, it's bug 392513 and a patch is already provided, though nobody has reviewed it yet. Dani: The problem is only for when the repository contains one project at the root (.project is in the same directory as .git).
Verified in 2.2.0.201211020023.
