Skip to main content
aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.egit.ui.test/src
AgeCommit message (Collapse)AuthorFilesLines
2016-05-30Test stability: wait for specific child node after expansionThomas Wolf2-3/+45
The first test in GlobalConfigurationPageTest frequently fails on Hudson because it doesn't find the child node "Configuration". It appears that child nodes in the preference page's tree are added one after another, so waiting until there is any child is not good enough: "Configuration" is the second child and might not have appeared yet. Change-Id: Ic5690b481b111fe98aa6d8da1108d5ee462c6e1a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-29Test stability: wait for index diff cache updateThomas Wolf1-0/+3
Apparently the DisconnectConnectTest.testDecorations() not always waits long enough for the decorations to appear. Decorations are triggered by an index diff cache update, so let's wait for that first, and only then for the decoration job. Change-Id: I5b32299006a99f3332b49e70d1fcdbfa375d362f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-25Test stability: after clicking finish, wait for shell to close.Thomas Wolf1-5/+14
Eliminate Thread.sleep() calls, which is a sure recipe for unstable tests. Instead wait for the shell to close, and since we then test properties of workspace resources, refresh the workspace first. Change-Id: I96fa669d655bd0118fb49e599cd3538bb555bc71 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-22Replace uses of deprecated Repository.getRef()Thomas Wolf10-13/+14
Use Repository.findRef() or Repository.exactRef(), as appropriate. No functional change. Change-Id: Ie481c7fa5ac69d4778cf9f70ac2b019bee6e53c9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-09Set repository when opening staging view from commit actionThomas Wolf1-0/+105
Otherwise the view will come up with "No repository selected" when "link with selection" is disabled. Bug: 491907 Change-Id: Ia4c2db8201c7f2c038fb873ca78366d7d1feb67f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-07Test stability: one "widget disposed" message is enoughThomas Wolf3-1/+12
If a widget is disposed while we're waiting on its expansion, we would get umpteen log entries until the waiting timed out. Let's stop waiting instead, and then fail the test. Also, it appears that GitRepositoriesViewTest.testImportWizard() gets a repo view refresh at an inopportune moment. I don't quite see yet where this is coming from, but let's wait for refresh jobs after having closed the dialog the first time. Finally, FeatureFinishSquashHandlerTest expects a dialog to be opened and wants to enter text there, but didn't wait for that dialog to appear: another source of spurious test failures. Change-Id: I14f365d86dda032dbaabd593e95a7bec432c0e21 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-05Test stability: really shut down repositoriesThomas Wolf2-0/+2
Otherwise, repositories from previous tests may remain registered, and may at some later point found to have gone and a new refresh of the repo view may be scheduled. As a result, we may have asynchronous refreshes that occur during SWT bot tests, and tree nodes disappear at unpredictable moments. Also: in commitNonWSChangesTest, repo view is opened after a commit and thus must also wait until the repo view refresh is over before trying to find tree nodes. Change-Id: I43ff9bee19fb4983cd44486a4085640f2dac0497 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-04Test stability: wait for repositories view refresh after config changeThomas Wolf1-0/+1
The repositories view updates itself on a config change event. The test must wait until that refresh is over, otherwise tree nodes may disappear while we're waiting for them to be expanded, resulting in "org.eclipse.swt.SWTException: Widget is disposed". Change-Id: I0a72897bcb919b0da2bc81e124cc8c0c2cf9a171 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-03Test stability: after clicking finish, wait for shell to close.Thomas Wolf1-0/+2
The failure in build 8454 was apparently caused by the test switching to the repositories view before the create branch dialog had closed. Change-Id: Ic2e871f5a9da81dd68d9c43758f99118f57428d1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-05-03Test stability: avoid asynchronous SWTBotTreeItem.expand()Thomas Wolf23-220/+287
Sometimes tests do not find children of expanded tree nodes. The root cause appears to be that expand() expands the node in an asyncExec.[1] Add a utility operation that after expanding waits until the desired node exists, and replace all calls to expand() that do expect children by that. [1] https://wiki.eclipse.org/Linux_Tools_Project/SWTBot_Workarounds#Tree_Item_Expansion_Failure Change-Id: I23ea6a7bc519692c0e9dbe480bb2eb8dfb96adc1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-04-03When running "Commit" action open staging view instead of commit dialogMatthias Sohn5-0/+35
Add a preference to allow switching back to the old behavior of the commit action to open the commit dialog. By default it now opens the staging view. After opening the staging view auto-select and set focus on unstaged files if there are any, otherwise set focus on the commit message. The commit dialog is still used by CleanupUncomittedChangesDialog. Bug: 490121 Change-Id: I604f31268f83ab11c3f3a869edf3c7121f0e6478 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-03-22Test stability: fix FeatureFinishSquashTestThomas Wolf1-19/+5
The test didn't wait for the shell to open in AbstractFeatureFinishHandlerTest.finishFeature(). Unfortunately, that shell didn't have a title, and was thus a bit inconvenient to wait for. * Give that shell (a TitleAreaDialog) a title. TitleAreaDialog.setTitle() does not set the shell's title! * Simplify the code: use the async clickContextMenu instead of the sync variant wrapped in an asyncExec. Change-Id: I5e26490682821888b4f62da8a323cbc1aeeaded4 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-21Remove session properties when disconnecting a projectThomas Wolf1-0/+20
Disconnecting a project left the session properties for the RepositoryMappings still attached to the resource info in the Eclipse resource tree. This prevents timely garbage collection of no longer used repository instances because the mappings contain hard references to repositories. Moreover, potentially stale properties might become active again when the project is re-connected. Change-Id: I845c708d3d98ba285c8db94edd2ed14deebd29fb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-20Fix refresh after re-connecting a project with submodules insideThomas Wolf1-5/+5
Follow-up to commit a8bcee9. When a previously connected, then disconnected project is re-connected, there is no resource change event. Thus the GitProjectData doesn't pick up inner repositories, and doesn't re-set the RepositoryMappings for folders inside the project that contain submodule or nested repository working trees. Because of another bug that I plan to fix soon (disconnecting a project does not remove the RepositoryMapping session properties), this problem is currently only visible if one quits and restarts Eclipse after having disconnected. (Otherwise, the previous session properties are still set, and everything appears fine.) Thus we need to make sure when a project is shared that we get at least a resource delta including all .git files and folders in the hierarchy. Ensure that by touching all such inner resources. Also, the SharingWizard must not suppress the refresh. Bug: 489696 Change-Id: I1bce767f54bffced241d2a0ad3c7ae8230152199 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-15Refresh decorations after re-connecting a projectThomas Wolf4-19/+47
Re-connecting a previously connected, then disconnected project did not refresh the decorations in the project explorer. RepositoryChangeListener was unused, and likewise GitProjectData.addRepositoryChangeListener(). Therefore, all calls to RepositoryMapping.fireRepositoryChanged() had absolutely no effect. Thus I have removed all these calls and the method. Interesting bit of EGit history: the very first version (even before EGit became an Eclipse project) of GitProjectData contained what is now known as the RepositoryCache (the one in EGit). The RepositoryChangeListener indeed was notified on changes in a repository. In that original commit, there was exactly one such listener: in the git decorator. Through various refactorings, RepositoryCache was extracted from GitProjectData, and then IndexDiffChangedListener appeared. RepositoryChangeListener became unused; GitLightweightDecorator was changed to listen on index diff changes in commit f332331. Nowadays, this RepositoryChangeListener is notified not on repository changes, but whenever a new RepositoryMapping is added to the Eclipse resource tree. And that is exactly what is needed to fix bug 489696: when a previously connected, now disconnected project is re-connected, there will be no resource change events (the project is known in Eclipse's resource tree already, and adding new RepositoryMappings as session properties doesn't trigger a resource delta). There also will be no repository or index diff related events (provided the repository is still known to EGit, for instance because it is in the Repositories view, or because there are other projects from that repository.) So the GitLightweightDecorator will not refresh decorations. Using a RepositoryChangeListener (again, after 5 years) the GitLightweightDecorator can correctly refresh the project explorer in this case. Since this listener is no longer invoked when a repository changes, but when a new RepositoryMapping appears, I have renamed and re-purposed the interface to RepositoryMappingChangeListener. Bug: 489696 Change-Id: I2b59cea1f1500cbdde554fff28b676456c8462d8 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-14Support copy/move of workspace if Git repository is under workspaceMatthias Sohn1-2/+4
If git repositories are located under the workspace path moving or copying the workspace broke the repository path information in .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.egit.core.prefs since all repository paths were stored as absolute paths and paths of repositories located under the moved or copied workspace weren't matching this persisted paths anymore. Fix this by storing the repository path relative to the workspace root if a repository path is located under the workspace root. For repositories not located under the workspace root still store the absolute path since otherwise their path would break if the workspace is moved or copied. Store this in a new preference and still maintain the old preference with list of absolute repository paths in order to ensure compatibility with older EGit versions. Bug: 358285 Change-Id: Ib73b76eb1d63587a767fec59c076fbe51c75e2f1 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-03-13RepositoryCache: do not prematurely remove submodulesThomas Wolf4-12/+228
Basically we have no way of knowing when we no longer reference a repository. In our code alone, there may be RepositoryMappings and RepositoryNodes directly referencing a Repository, but some views may also have direct references to Repository instances. We therefore cannot explicitly remove repositories from the RepositoryCache, since we have no efficient and 100% reliable way to determine whether a Repository is still in use somewhere. Therefore the RepositoryCache relies on weak reference semantics. Before https://git.eclipse.org/r/#/c/62066/ , this whole mechanism was broken anyway because the IndexDiffCache had no way to remove an IndexDiffCacheEntry instance, and those instances had hard references to the Repository. So once there was an IndexDiffCacheEntry for a repository, that Repository instance would be kept forever. https://git.eclipse.org/r/#/c/62066/ itself was a wrong approach because it neglected that some repositories might never be "configured" repositories visible in the Repositories view. Such repositories would be removed from the RepositoryCache while still in use. Submodules and nested repositories are affected by this, but so can top-level repositories. The approach taken in this change here fixes this. First, we go back to relying solely on the weak reference semantics of the RepositoryCache. Note that doing so does not give any guarantee about when exactly a no longer used and only weakly reachable Repository instance will actually be removed from the cache. Then we at least make sure that we don't keep any hard references around. That's more difficult than it may seem: * Replaced all hard references to Repository in IndexDiffCacheEntry. We now only use the repository's git directory, and use that to get the repository from the RepositoryCache, if it still is there. * The oldIndex DirCache in an IndexDiffCacheEntry also had a hard reference to the Repository. Use a DirCache.read() variant that doesn't set that link -- it's used only for writing a DirCache, which we don't do. Note that this is a bit fragile as it relies on an implementation detail of JGit, but for now I see no other way. * Even worse, some Eclipse internals do keep around hard references to some "last selection"s. Those may contain no longer used RepositoryNodes from the repository view, which still reference the Repository instance through a hard reference. We have no real way to reliably ensure that these Eclipse internals forget those nodes. Therefore we have to ensure in RemoveCommand that we actually do null out these Repository references once we're sure we have removed the node from our view. (The two places I found where Eclipse holds on to such defunct nodes are WorkbenchSourceProvider.lastShowInSelection, set when the "Shown In..." context menu was last filled, and the CommonViewer, which also remembers the last selection.) * Our own RepositorySourceProvider had a private field referencing the last selected Repository. The RepositorySourceProvider is a singleton that is instantiated very early and then kept around forever. That was resolved by using a weak reference for the repository. * The EclipseContext also managed to (indirectly) hold on to a hard reference to a Repository instance through the context variable we provided. That was solved by not passing the Repository directly as the context variable defined by RepositorySourceProvider but again only the git directory. * RebaseInteractivePlan has a static global cache of plans and each plan had a hard reference to a repository. A plan is computed when the view is opened, even if never executed. That accumulated hard references to repositories. Solved by using a weak reference. * The Eclipse resource tree's DataTreeLookup has a static cache of instances that are re-used but not cleared after use. Those may keep references to our RepositoryMapping session properties for some time after the IResource to with the property was attached has gone. The test explicitly accounts for this. In the full test run in maven, more problems showed up in a heap dump taken just before we test for no cached repositories in GitRepositoriesViewRepoDeletionTest: numerous FileRepository instances from earlier tests were still referenced. * The EclipseContext retains some handler activations of ActionHamdlers of anonymous Action subclasses of SpellcheckableMessageArea, which reference the area through this$0, which itself keeps a reference to the CommitDialog through this$0, which means we keep the CommitMessageComponent, which has a hard reference to the Repository. Solved by using static subclasses that reference only the SourceViewer. * The Eclipse NavigationHistory keeps around references to some CommitEditorInputs, which also have a hard reference to a repository. * The synchronize view references a repository through its GitSynchronizeData. Resolved in test by keeping the synchronize view closed. * The FileRepository from testCompareWithPreviousWithMerge was still referenced from the job from CompareWithPreviousActionHandler even though no such job was running anymore. Referenced in the ProgressMonitorFocusJobDialog, which was still kept around through its fontChangeListener (an inner non-static class in the ultimate ancestor class Window), which apparently somehow was still registered.. Unclear why or what happened there. Not resolved. * Same thing with testRevertFailure; referenced from RevertCommitOperation from the job in RevertHandler from ProgressMonitorFocusJobDialog. Unresolved. * Anonymous actions in SwitchToMenu still reference a long gone repository from test method selectionWithProj1. Unclear why and unresolved. * Some repositories from earlier tests were still referenced through long defunct RepositoryNode instances. Unresolved. * RepositoryPropertySourceProvider has a hard reference to its lastObject, and the RepositoryPropertySource has hard references to the configs, which may have hard references to the Repository. Resolved in test by closing the property sheet; unresolved in general. Because we can't explicitly remove items from the RepositoryCache, we also cannot explicitly remove IndexDiffCache entries. The only thing we can do is to ensure we remove IndexDiffCacheEntries when we detect that a repository in the cache no longer exists (has been garbage collected, or its git directory no longer exists.) Additionally, the resource change listener of an IndexDiffCacheEntry unregisters itself when it finds its repository has gone. I cannot really claim that this still fixes bug 483664 because there is absolutely no way to ensure that repositories vanish from the RepositoryCache in a timely manner. But it's a best-effort attempt to at least try, and at the same time not to evict repositories from the cache prematurely. The test explicitly invokes System.gc() in an attempt to make the JVM actually reclaim weakly reachable objects. This is not guaranteed, but appears to work in practice: the test thus only shows that the obvious places where we kept hard references are indeed resolved, and the repository does indeed vanish eventually. But see the "unresolved" items above: there's no guarantee that some view or action handler or Eclipse internal class doesn't somehow still manages to keep a hard reference and thus prevent reclamation. Finally, testing for an empty RepositoryCache must ensure that the RepositoryChangeScanner does not interfere; otherwise that may temporarily hold hard references to repositories. Solved using a scheduling rule. Change-Id: I3f437caccd58d6c9fb4187f66d9f53e7834a5224 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-02Test stability: GitRepositoriesViewRepoDeletionTestThomas Wolf1-6/+3
Must click the menu synchronously. Change-Id: I5dda8ddd48387670c36e12bd6057ac415cef2cc2 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-29Decorate IFolders that are submodule working directory rootsThomas Wolf1-0/+18
Introduce a new configurable submodule text decoration used for folders that are submodule working directory roots. (Or working directory roots of nested repositories.) The default shows the a dirty indicator, the branch, branch state, and the head commit's short message. The repository name is omitted since it'll always be identical to the folder name. Added a new variable for the short message of the head commit. Change-Id: I75460fd59f2e6c9bd06e82a1966e3d06f97ab709 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-28Test stability: properly wait for refresh jobs in Gitflow testThomas Wolf1-3/+5
SWTbot tests shall never ever just sleep(). That's a sure recipe for an unstable test, and caused the instability in FeatureFinishSquashHandlerTest. Better wait for a defined job family, if available, or even better until a defined event occurs. Here, however, we have neither a family nor an event to wait for. Resort to waiting until things have quieted down. Also use setText() instead of typeText(); the latter may fail if the keyboard layout is unknown to SWTbot (such as my MAC_DE_CH layout). Change-Id: Ib2e4819a7af91450140a140e2b3f797d24ae9396 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-25Fix recognition of submodules in folders.Thomas Wolf2-0/+314
Most of the basic plumbing for this was already in place, but it looks as if the implementation was never really finished. For instance, GitProjectData is prepared to record RepositoryMapping on container level, not just for projects. The feature was just not used, and many places in EGit make assumptions that imply that a project is fully within one repository. This is a first commit to get rid of this assumption, and to properly deal with submodules that exist only as folders in the Eclipse workspace. Augment the already existing resource change listener in GitProjectData to also handle additions of DOT_GIT resources. In that way it'll pick up submodules as they appear in the Eclipse resource tree. RepositoryMapping.getMapping(IResource) must consider mappings entered for folders below the project level. One mustn't jump directly to project level; that will skip any submodules that might have been applicable. StagingView: no need anymore to use a submodule walk. The RepositoryMapping for any resource will point to the correct repository, even if it's a submodule. Not using a submodule walk also avoids problem with the walk returning non-normalized git directory paths that may contain ".." segments, while our RepositoryCache uses normalized paths. This may yield two versions of the same repo in the cache, and listening for index diff changes on one wouldn't trigger on the other. GitResourceDeltaVisitor: must descend into folders even if the repository doesn't match on project level. Otherwise submodules are not updated. For scheduling rule calculation, it is not sufficient to search for projects in the repository's working directory. One also needs to include projects containing the repository working directory. Deprecated: * RepositoryMapping.getSubmoduleRepository(IResource) Also changed some uses of RepositoryMapping.getMapping(IProject) to RepositoryMapping.getMapping(IResource). I'd like to have deprecated the project variant, but this needs more careful analysis of the remaining places its used. Properly adding submodule mappings and considering them fixes at least bug 446344, comment 11. Also related is bug 401556, though that was reported for the behavior in the Repositories view, which isn't fixed by this commit yet. However, a selection in the project explorer for a folder belonging to a submodule showed the same erroneous behavior. Added new tests. Bug: 446344 Bug: 401556 Change-Id: I4caa06113b5280114a7816f2c3932711b2fedf08 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-22Allow filtering of Gitflow feature branches in checkout and track dialogMax Hohenegger1-1/+7
Working with a larger number of feature branches can be tedious, if there is no way of organizing them. A quick way of finding, known, well-named branches, can be a simple text filter. - replaced lists with filtered trees - extended UI test Change-Id: Ifc82c1fece1ed45b6ce929dcd39ecb913ce4615f Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-21Test stability: GitRepositoriesView testsThomas Wolf1-3/+30
Test failure in [1] claimed that no refresh job was scheduled. The RepositoriesView schedules a refresh on its own in response to an index diff change. If a refresh job is already scheduled and not running yet, the re-schedule in view.refresh() has no effect. See JobManager.schedule(). As a result, the JobListener is never notified about a scheduled job. Moreover, if the job is already running, re-scheduling will make it run again, but the JobListener will return already when the currently running job finishes. Therefore, we just need to wait for refresh jobs after having called view.refresh(). That will make the test wait in any case. Timeout can be implemented via a custom progress monitor. [1] https://hudson.eclipse.org/egit/job/egit.gerrit/8154/testReport/junit/org.eclipse.egit.ui.view.repositories/GitRepositoriesViewBranchHandlingTest/testCheckoutRemote/ Change-Id: I2ecd20b4caaf70e00a903366f46da0075afa6a3f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-17Test stability: SynchronizeViewGitChangeSetModelTestThomas Wolf1-3/+5
The test was looking for a tree node with label "GeneralProject". As the screenshot from unstable build 8131[1] clearly shows, the node is labeled "> GeneralProject". Looks like there's some asynchronous decoration going on, and depending on whether the test tried to get the node before or after the decorator ran it would succeed or fail. Remedy by using TestUtil.getNode(), which only requires a substring match, instead of SWTBotTreeItem.getNode(), which requires an exact match. Also relax the assertion on the "<working tree>" node (same as in the following test method). There may be more similar problem spots lurking in here. [1] https://hudson.eclipse.org/egit/job/egit.gerrit/8131/artifact/org.eclipse.egit.ui.test/target/screenshots/shouldRefreshSyncResultAfterWorkspaceChange%28org.eclipse.egit.ui.view.synchronize.SynchronizeViewGitChangeSetModelTest%29.jpeg Change-Id: If0051411196ac0148f2a6289d1dfba1e3d69f61d Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-17Fill FetchFromGerrit wizard for more clipboard contentsThomas Wolf1-0/+140
Try to extract a change number from more kinds of clipboard text: URLs, if they look like a Gerrit URL, as well as * simple integers, possibly surrounded by slashes * up to three integers separated by slashes * any of the above followed by /something,like for instance a Gerrit diff screen URL Should handle full and partial Gerrit URL selections, as well as "naked" change numbers. If a change number is detected, content assist is triggered automatically. New tests for change number detection are included. Bug: 486253 Change-Id: I35ea30947343ccaf09b2a6cf4104ad5f35cdda4b Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-13Ensure "Push HEAD..." action is enabled also when HEAD is detachedMatthias Sohn3-4/+49
Fixing a regression introduced by https://git.eclipse.org/r/#/c/63972/ Push should be enabled if HEAD directly or indirectly refers to a commit. Bug: 487078 Change-Id: I13a28252472957ac172fa91fe89406e736f6a34a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-13Wizard to configure pull operationMickael Istria1-0/+104
This is accessible on project's context menu, as "Pull..." just below "Pull". The wizard enables the user to specify the remote or add a new one, and also to specify the remote reference. There is content assist for published remote references, but the user may also pull from non-published remote refs, such as pull requests on Github or patch sets in Gerrit. Bug: 485124 Change-Id: I88122d3fedf10de35a0c1c233b7dd9920bb8c0c7 Signed-off-by: Mickael Istria <mistria@redhat.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-11Make AddToIndex/RemoveFromIndex work for multiple repositories againThomas Wolf2-21/+207
Commit 4e89050 inadvertently introduced the restriction that all resources in the selection be in one repository. However, AddToIndex, RemoveFromIndex, and Ignore previously also worked if projects from different repositories were selected. Remove the restriction on a single repository from the ResourceStatePropertyTester, and simplify the isEnabled() of AddToIndex and RemoveFromIndex action handlers a bit. The ResourceStatePropertyTester is currently used only for these commands in the Team context menu. If is ever to be used with some command for which all resources really must be from one repository, it can be combined with the "resourcesSingleRepository" property test. Performance should not suffer as all repository or index diff operations in the property tester operate on caches. Add new tests to test the "Add To Index" and "Remove From Index" actions for single and multiple repository selections. Change-Id: I71b1ece61cceeb08ee775e7afae33beee2b57b9f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-11Fix logic for detecting whether there are unstaged changesThomas Wolf1-0/+11
Didn't account for conflicts. Add a new hasUnstagedChanges() to IResourceState to have the calculation in (preferrably) one place. (Ok, StagingEntry must re-implement it.) Add assertions in the existing tests in DecoratableResourceAdapterTest for the new operation. Bug: 486983 Change-Id: Iffc29c16f247199945775d37dc719713d087ac64 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-01-26Make the gitflow UI tests independent of the keyboard layoutThomas Wolf3-8/+6
Use setText() instead of typeText(); otherwise these tests fail unless the keyboard layout happens to be en-us (or mac-en-us). Bug: 475804 Change-Id: I891dd82174f43f12a93cae03fad1a68dfc3ae0dd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-01-20Properly clean up caches when a configured repository is removedThomas Wolf1-2/+48
When a repository is removed, it was never removed from the IndexDiffCache, which in fact has no operation to remove anything. Only the preference in ResourceUtil is updated. This of course in turn means there's a hard reference in IndexDiffCache to the repo, and it thus also remains in the RepositoryCache indefinitely (unless it is really deleted, not just removed from the view). Clean this up: 1. IndexDiffCache listens on changes to the preference storing the configured repositories and removes any stale cache entries upon changes. 2. Individual cache entries really clear all listeners, and cancel their jobs when disposed. 3. The RepositoryCache also listens on that preference and also removes stale entries proactively. Bug: 483664 Change-Id: I8c20d4e8821e6c5d9fa7e62191a79275bef58bce Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-01-07[test stability] trying to stabilize recently failed unstable testsAndrey Loskutov1-2/+5
Change-Id: Ibf8298ebd16ec55a7320aeef5303b6006432f8ca Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
2015-12-30Add tests for Gitflow command enablementMax Hohenegger4-11/+137
- package explorer on project selection Change-Id: I96eda381a8d909b48e538c09d4e1c535ba71b81b Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2015-11-30Extract non-decoration things into new IResourceStateThomas Wolf1-8/+8
Separates UI-related things like branch names (actually labels) from the state of the file in the repository and enables use of this state elsewhere without incurring overhead for name calculations. Bug: 355809 Change-Id: If283be82612b15d14c773eea628777eb79f263ae Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-10-26Do not wrap commit message footer linesThomas Wolf2-0/+59
Wrapping commit message footer lines may break the expected format of those lines. Bug: 478659 Change-Id: I0169c4cc278318a702bbed2c6e5d7ff99038406f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-10-21Minor improvement in test for repository deletionThomas Wolf1-1/+6
Besides verifying that the shared project has gone from Eclipse when the repository is deleted also verify that the project is gone on disk, and (since that project was the only one there) even the whole working directory is gone. Instead of just checking for the working tree, do check for each one explicitly so that in case of a failure it's clearer what exactly failed. Change-Id: I8676c0c173ff923ccd799ff9d490c7f8152bbd17 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-10-17Don't delete projects on disk unless the user said soThomas Wolf1-0/+41
If the user chooses not to delete the working tree when deleting a repository the projects from that repository must not be deleted but only removed from the workspace if the "Remove projects from workspace" option is checked. Bug: 479964 Change-Id: I4435d049703f207224b0847a20742d240483abdf Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-09-23Allow saving feature finish options as defaultMax Hohenegger5-0/+45
- added checkbox to feature finish dialog - save defaults to preference store - re-store options from preference store - extended UI tests Bug: 478056 Change-Id: I232c338dab209dd0829f3fdb683b64441e22b7b0 Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu>
2015-09-22Refactored feature finish UI tests to reduce redundancyMax Hohenegger4-169/+123
Change-Id: I4f70f569736d171eddfc11088bb210939eede659 Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu>
2015-09-21Added support for keeping branch after Gitflow feature finishMax Hohenegger3-3/+121
- added new option to API - added checkbox to feature finish dialog - added tests and UI tests Bug: 477786 Change-Id: I4e58529378c976c83b7564e817db6f7be00d0cec Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu>
2015-09-20Obey hyperlink preferences in SpellcheckableMessageAreaThomas Wolf1-2/+19
and in CommitMessageViewer in git history. 1. Only open hyperlinks on direct click in read-only views; in editable views, this is too confusing and too often opens the hyperlink when the user just wants to set the caret. 2. Make the viewer react on changes in the general hyperlinking preferences. Both for the master switch and for individual contributed hyperlink detectors. 3. Ignore disabled hyperlink detectors in syntax coloring (by not storing them once and for all times in HyperlinkTokenScanner but getting them freshly from the viewer configuration for each run). 4. Always keep the special git history navigation links enabled in the CommitMessageViewer (KnownHyperlinksDetector). The JFace hyperlinking infrastructure actually only supports hyperlink detectors that either open on a specified modifier key combination, or on the default combination, which is the one the viewer sets, which is normally the one from the global preferences. If a viewer thus sets SWT.NONE to support direct hyperlinking, the global preferences will not take effect for hyperlink detectors that specify "default", which leads to a rather inconsistent interface, because hyperlinks are then only active when no key is pressed, but become inactive when the modifiers from the global preferences are pressed. We work around this by actually duplicating hyperlink detectors when the viewer specifies SWT.NONE. This ensures that hyperlinks can be opened (in read-only views) either by direct click or also when the modifier given by the global configuration is pressed. Bug: 411809 Change-Id: Icfcfe62b127370be36bced8b1430b764d31b75a6 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2015-09-17Add missing @Override annotations to all EGit bundlesLars Vogel29-0/+78
Bug: 477689 Change-Id: I490e6558db5133a60caf00af2b996feae0e2e832 Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2015-09-13Check for objects adaptable to IResource in ShowBlameActionHandlerThomas Wolf2-59/+359
Includes a new test. Some refactoring in LocalRepositoryTestCase to avoid having to duplicate test repo creation, and to reduce code duplication. Bug: 401156 Change-Id: Ib78d62f11d3a5a52c672bb192e8baba189c49829 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-09-10Rewrite CommitMessageViewer to use JFaceThomas Wolf1-9/+7
The goal is to get the commit message viewer in the git history view to use the same (configurable) hyperlink colors and other hyperlink infrastructure as the SpellcheckableMessageArea. This is complicated by two things: * custom hyperlinks to commits with custom opening, and * no clear model-view separation; getting the data from git, formatting, and coloring were all lumped together. Therefore, improve the model-view separation: * Get rid of hand-crafted SWT text range coloring. CommitInfoBuilder is restricted to getting the data from the repo, formatting, and returning semantic information (hyperlinks, header and footer ranges). It doesn't do syntax-coloring anymore. * CommitMessageViewer uses a partitioning on its document to split it logically into header, body, and footer. It also gets a custom hyperlink detector to deal with the custom commit hyperlinks. * GitHistoryPage uses a presentation reconciler with damager/repairers that know how to syntax-color each partition (and hyperlinks). * Made the HyperlinkTokenScanner a bit more flexible to rebuild the italicizing of Signed-off-by footer lines. Fixed a bug along the way (if "fill paragraphs" was on, it would put footer lines onto one line). Visually, there are no changes except the colors of hyperlinks, which now follow SpellcheckableMessageArea and are configurable. Bug: 340623 Change-Id: Ie1b5907110ba716d262e4b5773fed7e3a5150d0d Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2015-09-10Fixed: Specifying non-existing master does not abort initializationMax Hohenegger1-20/+116
- abort init operation if master is missing - added validator for missing master branch - ask user to create master branch - ask user to create initial commit if repository is empty - added control decorations to hint at source of problem - adjusted tests Bug: 475788 Change-Id: Ief9b1a361a3dce83358e7b84034bb6a477ec92e4 Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu>
2015-09-07Simplify hyperlink syntax coloring in SpellcheckableMessageAreaThomas Wolf1-3/+9
Turns out we don't need to use a special TextAttribute, and neither do we need a special damager/repairer. Works nicely out of the box. Change-Id: Id2f0d36f3c2018c047ad1f4cf65e148c960f236d Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-09-07Use standard link colors in SpellcheckableMessageAreaThomas Wolf1-4/+5
There are at least three different color definitions for hyperlinks in Eclipse: JFacePreferences, EditorsUI, and a system hyperlink color. Use standard colors instead of hard-coded blue (0,0,255). Syntax-color hyperlinks using the JFace HYPERLINK color, and make the hyperlink presenter use the configured hyperlink color for editors. Both of these can be customized by the user through (already existing) preferences and thus can be adapted to the currently used theme. (Harmonizing the discrepancy between the JFace and the EditorsUI colors is bugs 199256/135224.) Change-Id: Id0d058018ee8f6fa2279371c3f5786a3dc24b690 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2015-09-02Fix hyperlink display in SpellcheckableMessageAreaThomas Wolf1-0/+122
This is first and foremost a syntax coloring problem, and should be handled as such. This change implements that: * Adds a token scanner that recognizes hyperlinks using the configured hyperlink detectors. * Adds a presentation reconciler with a damager/repairer that uses this token scanner. * Gets rid of the overridden hideHyperlinks() method -- if we do proper syntax coloring, this can wreck havoc when the text is edited (the super implementation does some StyleRange cleanup; if that is omitted, a stale and possibly out-of-bounds range remains). * Uses SWT.UNDERLINE_LINK to style hyperlink partitions. * Adds a few unit tests for the tokenizing. * Adds org.objenesis to required bundles in org.eclipse.egit.ui.test to enable mocking. In my manual UI tests, this syntax-colors hyperlinks nicely in the staging view, spell-checking works, auto-wrap works, whitespace display works, the "hand" pointer appears only over hyperlinks, and bug 471355 is solved. It also has no adverse effects on the commit viewer or the git history view. Bug: 471355 Change-Id: I623ead62d9600028973353cf63183638a1e06a3e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2015-08-24Initializing a Gitflow repository should allow changing branch namesMax Hohenegger1-4/+59
- added new dialog that opens when initializing the repository - changed API for "git flow init" to accept a config PoJo - deprecated redundant API - added UI test Bug: 475293 Change-Id: If7e314d749b0fcd3e77eb82576336c1aa20d4d14 Signed-off-by: Max Hohenegger <eclipse@hohenegger.eu>
2015-08-23Show that there are changes in "Git Repositories" viewPeter Karena3-10/+13
Equal to the modification of a file, where the sign '>' is added to the filename, the same character is added, when a file in a repository gets changed. It's very usefull when you work with many repositories. Change-Id: I5fe30cb738c0ec5334430fc710d2d826deaebff1 Signed-off-by: Peter Karena <peter.karena@arcor.de>

Back to the top