Bugzilla – Full Text Bug Listing
| Summary: | Deal with refresh hell once and for all | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Oyvind Harboe <oyvind.harboe> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | forums, matthias.sohn, robin.rosenberg, robin |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Oyvind Harboe
Did you try to enable "Preferences > General > Workspace > Refresh automatically" ? This works for me. What do you mean by "where files are modified without git's knowledge" ? Does this imply you are often modifying files using tools outside Eclipse ? EGit relies on the Eclipse resource model to better integrate with the workbench. This also improves performance. (In reply to comment #1) > Did you try to enable "Preferences > General > Workspace > Refresh > automatically" ? > This works for me. This feature causes other nasty side effects, which is why it is not enabled by default. Try projects with large number of files (>100k). I don't remember the details though, but mainly I think the problem is that it kills performance. > What do you mean by "where files are modified without git's knowledge" ? That should be "Eclipse or egit's knowledge" and not "git's knowledge". Edit or move a file from the command line for instance. > Does this imply you are often modifying files using tools outside Eclipse ? More often than not by the time I'm ready to commit/synchronize. Certainly I use tools that will never be part of Eclipse. E.g. in hardware/FPGA world there are tools that rewrite files under source control. > EGit relies on the Eclipse resource model to better integrate with the > workbench. > This also improves performance. One of the *great* things about the git command line tools is that they have excellent performance, even if they are not involved in the "edit" stage. Subversion has always wanted to have "support" from the tools that modify the files under source control or it gets angry by the time you do synchronize. This is made worse by the numerous .svn folders that litters projects under svn control. In all the years if Subversion, such "support" has never happened and I think the fact that git doesn't rely on such "support" as a non-functional requirement, is just a *great* design decision. I can definitely see how the situation is more complicated with Eclipse, but confusing modal requesters saying "the file changed on disk"(or something even less helpful) when using egit is ... well.... wrong. On which operations would you like to see an enforced refresh ?
If we hardcode that we put the refresh penalty you mentioned on all users.
So we would probably add another EGit preference to enable such enforced
refreshes.
> I can definitely see how the situation is more complicated with Eclipse, but
> confusing modal requesters saying "the file changed on disk"(or something even
> less helpful) when using egit is ... well.... wrong.
Could you elaborate this a bit more, I don't get what you mean here.
(In reply to comment #3) > On which operations would you like to see an enforced refresh ? > If we hardcode that we put the refresh penalty you mentioned on all users. > So we would probably add another EGit preference to enable such enforced > refreshes. I can't think of an operation where I wouldn't want a forced refresh. This would effectively be to do the same that the git command line tools do: make no assumptions about what happened since last time... view history, synchronize, commit, rebase, tag. On which operations does egit make an assumption that the files or git repository wasn't changed "out of band"? > > I can definitely see how the situation is more complicated with Eclipse, but > > confusing modal requesters saying "the file changed on disk"(or something even > > less helpful) when using egit is ... well.... wrong. > > Could you elaborate this a bit more, I don't get what you mean here. gitk's solution is to have an explicit "reload" and "refresh". I think perhaps the problem is that egit has a hybrid mode here where refresh is not automatic, yet it tries to update things automatically. Perhaps the solution is to go to different avenues: explicit and fully automated refresh? Thinking about it, I don't really know what Egit is trying to show me in the user interface. Is it the current situation on disk? Is it the situation on disk when the menus were rendered? Is it the snapshot egit took of the universe at some point + any changes I made through Eclipse + possibly some other things? (In reply to comment #5) > Build Identifier: M20100909-0800 EGit refreshes automatically if it detects changes in the index or HEAD. Two weeks after the version you refer to, a change was introduced that disconnected this refresh from the other workspace option. When a change is detected, the projects in the changed repo are refreshed. The detected is done on the the index and HEAD refs only. If you alter files without affecting the index or HEAD, then EGit will not pick it up. You must enable the automatic workspace refresh, which is a thousand times more costly. By default it checks every five seconds (hard coded) and by default it only checks when an Eclipse Window is active, thus avoiding problems when the git command line locks files for reading. Do not forget to also check the Refresh Workspace on Startup. Not doing that is asking for trouble. EGit only reacts on changes since the first time it hits a resource during the same session. Why five seconds? a) Long enough that a quick switch back and forth will not trigger a refresh. b) short enough to get a feel out quick automatic refresh c) I was too lazy to add a user configurable option for this one too. It would make sense to have one for specifiying the delay and also whether a refresh check should performed instantly when the Eclipse workbench windows is activated. There has been discussion about subscription mechanism for Eclipse that would use OS features to immediately let Eclipse know when things change outside its control. So far no such Eclipse API exists. (In reply to comment #5) > (In reply to comment #5) > > Build Identifier: M20100909-0800 The problem I have with this explanation is that there is no way I can explain this to users and that they can use the information to "act correctly". The only solution that I have is to train users to do a refresh *always* before e.g. synchronize, compare, etc. The global text search capability in Eclipse is similarly a feature plagued with modal requesters that files changed on disk. I always have to do a refresh before using search. The major source of "unrefreshed" resources is that you do not have "Refresh on startup" checked. I see no reason not to (unless you are using clearcase dynamic views). That cannot be so hard to explain. That said, I don't think it would be wrong for Eclipse to automatically refresh resurces on-demand. There are questions to consider: Refresh only changed resources or refresh all resources in a project when one is found or even more? Though I think this is really an Eclipse feature, having a workaround in EGit, meanwhile could be useful. The refresh we already have is a similar workaround. P.S. I don't use the synchronize view myself, because I don't understand it in Git context. I use the Merge/Rebase/Cherry-pick command from Eclipse or the command line. Those commands change the index and that will trigger a refresh if needed. (In reply to comment #7) > The major source of "unrefreshed" resources is that you do not have "Refresh on > startup" checked. I see no reason not to (unless you are using clearcase > dynamic views). I'm talking about files that change while Eclipse is running. I'm using http://download.eclipse.org/egit/updates-nightly/, would it have the fixes you talk about? > P.S. I don't use the synchronize view myself, because I don't understand it in > Git context. "Synchronize" is a *terrible* choice of words. It implies that something will change. I wonder if it would be better to remove it from egit and promote compare more heavily. Really I'd want a "gitk" replacement... (In reply to comment #8) > (In reply to comment #7) > > The major source of "unrefreshed" resources is that you do not have "Refresh on > > startup" checked. I see no reason not to (unless you are using clearcase > > dynamic views). > > I'm talking about files that change while Eclipse is running. Yes, but you need do make sure all files are synchronized at the beginning of a session, either manually or by having an automatic refresh at startup. > I'm using http://download.eclipse.org/egit/updates-nightly/, would it > have the fixes you talk about? Yes. I also occasionally do things outside of Eclipse, but never had any problems with it when having configured automatic refresh it in preferences > General > Workspace. Eclipse also gained the option to use OS native hooks instead of polling the file system for this preference, so this should no longer be a performance concern. That this preferences is still not on by default is a problem with Eclipse itself, see discussions about this elsewhere. So closing this, feel free to comment in case you still don't view this as solved. |