Bugzilla – Full Text Bug Listing
| Summary: | 'Replace With > HEAD Revision' does not put previous version into local history | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Markus Keller <markus.kell.r> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, krzysztof.daniel, matthias.sohn, remy.suen, robin.rosenberg, robin, selsemore |
| Version: | 1.2 | ||
| Target Milestone: | 3.6 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=389078 | ||
| Whiteboard: | |||
|
Description
Markus Keller
This bug could void success stories like this one: http://eclipseandlinux.blogspot.com/2012/01/life-saving-eclipse-functionality.html Fixing this would probably mean introducing an abstraction like WorkingTreeIterator in JGit, but for writing files instead of reading. Or maybe we could even extend WorkingTreeIterator. The nice thing about this would be that we could also remove the expensive resource refreshes that we currently do after JGit operations. We currently refresh too much, e.g. all projects after a branch switch instead of only the changed files. A sad part is that the resource view all too often does not represent what's on disk. We can trust file system operations, but not resource operations. (In reply to Robin Rosenberg from comment #3) > A sad part is that the resource view all too often does not represent what's > on disk. We can trust file system operations, but not resource operations. I think this works more reliably when switching on the workspace option "Preferences > General > Workspace > Refresh using native hooks or polling" > We can trust file system operations, but not resource operations. No, you can also trust resource operations -- but only if you use resources as they are meant to be used. The whole resource model assumes that resources are only accessed via workspace APIs and not directly via the file system. In Git, that assumption typically doesn't hold, since the Git command line offers features that are not available in EGit. > works more reliably with auto-refresh enabled But it's still not reliable, so it's not safe to depend on that. You could rely on the "Refresh on access" setting, though: If that option is disabled, then it's fair to assume that a Git repo is not touched from outside of the workspace, so you can avoid explicit refreshes in that case. If "Refresh on access" is enabled (default setting), EGit should refresh resources before operating on them. I agree with Robin Stocker's comment 2 that resources should be accessed via the workspace APIs -- and as soon as that's implemented, there's no need to refresh anything after an EGit/JGit operation. (In reply to Matthias Sohn from comment #4) > (In reply to Robin Rosenberg from comment #3) > > A sad part is that the resource view all too often does not represent what's > > on disk. We can trust file system operations, but not resource operations. > > I think this works more reliably when switching on the workspace option > "Preferences > General > Workspace > Refresh using native hooks or polling" That only works on Windows or did that change? I've only used it very shortly because the scanning slows down the computer due to excessive disk I/O, uses too much battery power and reacts too slowly. I.e. not useful for anything but very small workspaces. Has it improved over the last two years? (In reply to Robin Rosenberg from comment #6) > > "Preferences > General > Workspace > Refresh using native hooks or polling" > > That only works on Windows or did that change? Correct, native hooks are still only used on Windows. See bug 108697 (Linux) and bug 237344 (Mac). Note that this is also a problem when you do a hard reset. Changes are discarded without being put in local history. I've submitted a patch for code review: https://git.eclipse.org/r/20675 Perhaps this will be considered a hack, as it resorts to performing a dummy update on the changed resources in order to trigger Eclipse to save them to local history. But it does work. FWIW, I implemented a similar change for the Subclipse plugin years ago. merged as f812540fa95ae0f89d853bce880920d7a2c22b17 |