Skip to main content
AgeCommit message (Collapse)AuthorFilesLines
2016-04-08Fix version.shMatthias Sohn1-2/+16
- don't change version of license-feature in org.eclipse.egit.mylyn-feature/feature.xml - update version of imported plugins org.eclipse.egit.core and org.eclipse.egit.ui in org.eclipse.egit.gitflow-feature/feature.xml - update version of required bundle org.eclipse.jgit in org.eclipse.egit.ui.importer/META-INF/MANIFEST.MF Change-Id: Ie890bf8fcf3c90350c3b9336b9a897981c6e8d64 Signed-off-by: Matthias Sohn <>
2016-04-08Merge branch 'stable-4.3'Matthias Sohn51-515/+509
* stable-4.3: Prepare 4.3.1-SNAPSHOT builds EGit v4.3.0.201604071810-r EGit v4.3.0.201604071045-r Update documentation for 4.3 Prepare 4.3.0-SNAPSHOT builds EGit v4.3.0.201603230630-rc1 Change-Id: I9a5e965c723278262578e77d5225d3126b499f7c Signed-off-by: Matthias Sohn <>
2016-04-08Prepare 4.3.1-SNAPSHOT buildsMatthias Sohn38-249/+249
Change-Id: Ide5a9401f66b246cab18e66d3a2046f7c22cabb6 Signed-off-by: Matthias Sohn <>
2016-04-07EGit v4.3.0.201604071810-rv4.3.0.201604071810-rMatthias Sohn38-39/+39
Change-Id: If4a677af68862a663b1fc0cdc56b867f9c7193b8 Signed-off-by: Matthias Sohn <>
2016-04-07EGit v4.3.0.201604071045-rMatthias Sohn38-39/+39
Change-Id: I26ca17f5ce5c83bea828ee642fdfcdf4708c25d7 Signed-off-by: Matthias Sohn <>
2016-04-07Update documentation for 4.3Matthias Sohn13-266/+260
Change-Id: Ice08fb833a653decf21d713f628115fee5e3ccc3 Signed-off-by: Matthias Sohn <>
2016-04-07Merge branch 'master' into stable-4.3Matthias Sohn27-117/+462
* master: For asynchronous dialogs, use the topmost modal shell Fix compile error in GitCompareFileRevisionEditorInput When running "Commit" action open staging view instead of commit dialog Auto-switch between horizontal and vertical StagingView layout Move EclipseAuthenticator and EclipseProxySelector to egit.core Move EclipseSshSessionFactory to org.eclipse.egit.core Diff error message should mention that the error is from Git Distinguish unchanged/deleted files in logical models Change-Id: I196cb3158eca8e6a2aca60dba7d47085a6ad8997 Signed-off-by: Matthias Sohn <>
2016-04-05For asynchronous dialogs, use the topmost modal shellThomas Wolf2-26/+16
Push and fetch results are shown in dialogs that * are shown asynchronously, and * moreover are triggered from inside jobs. I don't like jobs throwing dialogs at the user anyway, but I can see the desire here to run the potentially long remote operation in a job. Still, the PushToGerritPage does it without job... At the very least, such asynchronous dialogs, whether or not they themselves are modal, must use the topmost modal shell as parent. Using a parent, like the active window's shell, that already has a modal child may lock up the application. Bug: 487209 Change-Id: I460e625051e48ecedab0db7191a6dd8846dacc7d Signed-off-by: Thomas Wolf <>
2016-04-05Prepare 4.3.0-SNAPSHOT buildsMatthias Sohn38-39/+39
Change-Id: I018633c2417bae4f09cca5dafff97b5ba418e108 Signed-off-by: Matthias Sohn <>
2016-04-04Fix compile error in GitCompareFileRevisionEditorInputDani Megert1-3/+3
Change-Id: I63bf2e17b39b1c511fb49293ec92d98621ff0e26 Signed-off-by: Dani Megert <>
2016-04-03When running "Commit" action open staging view instead of commit dialogMatthias Sohn12-20/+99
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 <>
2016-04-03Auto-switch between horizontal and vertical StagingView layoutMatthias Sohn1-12/+37
Automatically switch the StagingView between horizontal and vertical layout when the view's height becomes larger or smaller than its width. Bug: 378600 Change-Id: Ife31672eee86631c19713eed54ed691ba0090b69 Signed-off-by: Matthias Sohn <>
2016-04-02Move EclipseAuthenticator and EclipseProxySelector to egit.coreMatthias Sohn7-22/+24
These classes don't have any UI dependencies hence move them down to the org.eclipse.egit.core bundle. Change-Id: I2da6c99bc32f155ad7b9bec21aac0fb0942a595b Signed-off-by: Matthias Sohn <>
2016-04-02Move EclipseSshSessionFactory to org.eclipse.egit.coreMatthias Sohn5-22/+25
This allows using this factory in headless environment. Preparation to expose an extension point to allow custom ssh session configuration. Bug: 489870 Change-Id: I7d4c7aff49b4f4c2f72739c51b0a07d1fc9e3a4a Signed-off-by: Matthias Sohn <>
2016-03-31Diff error message should mention that the error is from GitLars Vogel1-1/+1
I think the error message "Error occurred computing diffs" should include the info that it is coming from Git. As a user I got this error dialog and had to guess that this is related to Git. Bug: 490776 Change-Id: I611a2c3e4c37b159415045a0fb1d40fbdf0c5cea Signed-off-by: Lars Vogel <>
2016-03-25Distinguish unchanged/deleted files in logical modelsLaurent Delaigue4-12/+258
Change-Id: Iba967102da2118fcf795bdd3e4bc56c9ef8abec2 Also-by: Arthur Daussy <> Signed-off-by: Laurent Delaigue <>
2016-03-23EGit v4.3.0.201603230630-rc1v4.3.0.201603230630-rc1Matthias Sohn38-39/+39
Change-Id: I754b6d60ce877b7bfe970ae672bcab5ddccbfa00 Signed-off-by: Matthias Sohn <>
2016-03-22Fix Activator.error() calls that should have been Activator.logError()Thomas Wolf8-13/+14
error() just creates an IStatus. Replaced by logError() in all places where the returned IStatus was ignored. It's an easy mistake to make, especially since the UI Activator also has operations logError() and error(), but there both _do_ log. CommitMessageComponent should use the UI Activator, not the core one. Change-Id: I0a2a0d3be6454a757e2a17c10774deac52e96b89 Signed-off-by: Thomas Wolf <>
2016-03-22Test stability: fix FeatureFinishSquashTestThomas Wolf2-19/+6
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 <>
2016-03-22Fix repository search dialog to detect .git files under selected root.Andre Bossert1-24/+26
The search did not detect working tree with .git file in selected root folder. It always looked in sub-folders only and in case of .git folders it worked fine. Now it also checks the selected root folder additionally to its children. The Git private folders like .git folder itself are not traversed anymore. This prepares EGit to still properly detect git repositories when JGit change "" adds the evaluation of ".git" file with "gitdir" link to worktree and evaluates commondir. Bug: 477475 Change-Id: I9282c3431ca9946159f389168e4ad322ab42838c Signed-off-by: Andre Bossert <>
2016-03-22Do not swallow error in FetchGerritChangePage on finishThomas Wolf1-9/+14
internalDoFetch() must not handle the error but propagate it. When called from the background job, the job must translate exceptions into an appropriate status. Then let the job framework handle notifying the user of the error. Bug: 489679 Change-Id: Ia2bcdf267a6d83dfa89b60f217b223e15fdc5e4e Signed-off-by: Thomas Wolf <>
2016-03-22Improve error reporting in FetchGerritChangePageThomas Wolf2-46/+81
If a connection failure occurs during the change number content assist, the user feedback was poor. Some quick flickering of the progress bar and that was it. The error log contained a stack trace starting with two InvocationTargetExceptions without exception messages, which isn't exactly helpful either. Improve this in two ways: * Generally skip InvocationTargetExceptions with empty messages when reporting or logging errors. * In the case of the content proposal in the FetchGerritChangePage, show the error to the user. * Move the error reporting methods in Activator together. I completely missed at first that there was a createErrorStatus() further below... Change-Id: I9fa6bb6207539cff1c98850f7abf5d127077115c Signed-off-by: Thomas Wolf <>
2016-03-21Update index diff of parent repository when submodule changesThomas Wolf1-23/+62
When a repository contains submodules, the index diff cache entry must be updated on submodule changes. Otherwise branch switches in submodules go unnoticed in the parent. Change-Id: Ib23c557e69358f9e8a6dc5e085397e3aa2af8ef7 Signed-off-by: Thomas Wolf <>
2016-03-21Extended support for nested repositories in project.Andre Bossert2-34/+73
Refactoring of RepositoryMapping.getMapping(IPath) to make it support submodules and inner repositories. * RepositoryMapping * changed getMapping(IPath): searches in all project mappings * added getMappings(IProject): returns all mappings for a project * introduced getProjectData(): because needed in other methods multiple times Change-Id: Ie9aa6bd9df812c515e9f4967e1fb06c17e7cf636 Signed-off-by: Andre Bossert <>
2016-03-21Cleaning up the DecoratableResourceAdapterAndre Bossert7-14/+60
* IDecoratableResource, DecoratableResource etc: added isRepositoryContainer(): returns true if a resource is a repository container, like project, submodule or nested repository working tree root * GitProjectData: renamed hasSubmodules() to hasInnerRepositories() because not just submodules but all "inner" working trees (repositories) are supported Change-Id: Iec23af713554f6370dfd52c1c444cb7f41f465fd Signed-off-by: Andre Bossert <>
2016-03-21Fix potential NPE in IndexDiffCacheEntryThomas Wolf1-1/+7
It's possible that an IndexDiffCacheEntry is disposed while an IndexDiffUpdateJob is running. While we do cancel such a job, we do not join on it. We do, however, null out the previous IndexDiffData. A still running job therefore needs to be careful about using this property. I've seen this occasionally in our Hudson logs, the last time in [1]. [1] Change-Id: I88165cc20d4886444009c6654293ff461a777b02 Signed-off-by: Thomas Wolf <>
2016-03-21Remove session properties when disconnecting a projectThomas Wolf5-3/+64
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 <>
2016-03-20Fix refresh after re-connecting a project with submodules insideThomas Wolf3-7/+41
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 <>
2016-03-17Merge "Handle submodules in auto-sharing"Matthias Sohn3-15/+36
2016-03-15Handle submodules in auto-sharingThomas Wolf3-15/+36
When auto-sharing: * do connect projects to submodules * do not add submodules as "configured repositories" Change-Id: Ic27d694b3c0aa63e45e19523d8607d6326f21881 Signed-off-by: Thomas Wolf <>
2016-03-15Refresh decorations after re-connecting a projectThomas Wolf13-61/+82
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 <>
2016-03-15Merge "Fix a typo in a comment"Matthias Sohn1-1/+1
2016-03-15Merge "Support copy/move of workspace if Git repository is under workspace"Matthias Sohn4-17/+99
2016-03-15Merge "Document that hasGerritConfiguration() needs non-null repository"Matthias Sohn1-1/+3
2016-03-15Merge "Fix NPE in RepositoriesViewPropertyTester"Matthias Sohn1-22/+26
2016-03-15Fix a typo in a commentThomas Wolf1-1/+1
Change-Id: I617d37ff429254e74543200c9b41674328204fc1 Signed-off-by: Thomas Wolf <>
2016-03-14Delegate detection of git repositories to JGitAndre Bossert2-15/+12
This prepares EGit to still properly detect git repositories when JGit change "" adds the evaluation of ".git" file with "gitdir" link to worktree and evaluates commondir. Bug: 477475 Change-Id: Id1a54e0efb6fb7334ea4cb4a5507ed3e0bff0f7e Signed-off-by: Andre Bossert <> Signed-off-by: Matthias Sohn <>
2016-03-14Fix NPE in RepositoriesViewPropertyTesterMatthias Sohn1-22/+26
Bug: 489602 Change-Id: If35a2b22aeb34cf15afcf33410d34c7b22308f62 Signed-off-by: Matthias Sohn <>
2016-03-14Document that hasGerritConfiguration() needs non-null repositoryMatthias Sohn1-1/+3
Change-Id: I5e86c504d304a27ec914492651adae5e4387a731 Signed-off-by: Matthias Sohn <>
2016-03-14Support copy/move of workspace if Git repository is under workspaceMatthias Sohn4-17/+99
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 <>
2016-03-13RepositoryCache: do not prematurely remove submodulesThomas Wolf22-224/+627
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 , 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. 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 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 <>
2016-03-02Test stability: GitRepositoriesViewRepoDeletionTestThomas Wolf1-6/+3
Must click the menu synchronously. Change-Id: I5dda8ddd48387670c36e12bd6057ac415cef2cc2 Signed-off-by: Thomas Wolf <>
2016-03-02Fix wrong path comparison via file.getAbsolutePath().startsWith(..)Markus Keller1-10/+8
Path comparisons need to use proper path semantics. This is a follow-up to 5dc7ac99cb0b52ad87e2c563f5dfecf9a800e82c and fixes an IAE on Pull: "Attempted to beginRule [..] does not match outer scope rule [..]". Bug: 488862 Change-Id: I0dc3b287e86b3b01f4a560a97b5f4c2a783107c9 Signed-off-by: Markus Keller <>
2016-03-01Fix bug in RepositoryMappingTestThomas Wolf1-6/+6
Minor mixup between OS and portable strings went unnoticed on Unixlike systems and would fail on Windows. Change-Id: I21175bbaacde4793065c08f157cc3467b17adfcd Signed-off-by: Thomas Wolf <> Signed-off-by: Matthias Sohn <>
2016-02-29Decorate IFolders that are submodule working directory rootsThomas Wolf13-11/+115
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 <>
2016-02-29Safe preference reading of sash weights in GitHistoryPageThomas Wolf2-6/+27
Preference values shall be treated as unverified external input and be read in paranoid mode. Preferences can become corrupted; we can't trust them. In no case shall garbled preferences cause the application to fail. Armor reading of sash weights and fall back to the default values if the stored values cannot be read. Bug: 488666 Change-Id: Ib22dbf855c9dde10108b6a90cc9ca7fcd7688966 Signed-off-by: Thomas Wolf <>
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 <>
2016-02-27Always listen to POST_CHANGE events in GitProjectDataThomas Wolf2-5/+3
Offering the option not to listen to POST_CHANGE events makes no sense anymore; GitProjectData always needs to listen to these events in order to detect submodules in subfolders. Also, the only call to attachToWorkspace() passed true anyway. Change-Id: I4be95fe965f491296854f571098261a4ba4933fe Signed-off-by: Thomas Wolf <>
2016-02-27Fix sorting and grouping of staging entries by stateMatthias Sohn4-14/+40
- group all states, states which require attention more frequently come first - also sort staged changes pane - alphabetic sorting is the natural order and doesn't need explanation, hence name the button to toggle sort order "Sort by state" and use a new icon depicting that - rename the comparator to StagingEntryComparator since it's now used for both unstaged and staged changes Bug: 473919 Change-Id: Ia6c165f252bb293d77251e4b5cf9dfb63c1c5d53 Signed-off-by: Matthias Sohn <>
2016-02-27[staging view] Fixed sort order: added check for "names first" caseAndrey Loskutov1-10/+31
Bug: 487004 Change-Id: I59b0c32c8c077111ebc2e61026961332933e8b54

Back to the top