Skip to main content
aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2016-04-05Prepare 4.3.0-SNAPSHOT buildsMatthias Sohn38-39/+39
Change-Id: I018633c2417bae4f09cca5dafff97b5ba418e108 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-03-23EGit v4.3.0.201603230630-rc1v4.3.0.201603230630-rc1Matthias Sohn38-39/+39
Change-Id: I754b6d60ce877b7bfe970ae672bcab5ddccbfa00 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
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 "https://git.eclipse.org/r/#/c/67873/" adds the evaluation of ".git" file with "gitdir" link to worktree and evaluates commondir. Bug: 477475 Change-Id: I9282c3431ca9946159f389168e4ad322ab42838c Signed-off-by: Andre Bossert <anb0s@anbos.de>
2016-03-21Do 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 <thomas.wolf@paranor.ch>
2016-03-21Improve 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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
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 <anb0s@anbos.de>
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 <anb0s@anbos.de>
2016-03-20Fix 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] https://hudson.eclipse.org/egit/job/egit.gerrit/8298/console Change-Id: I88165cc20d4886444009c6654293ff461a777b02 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-03-20Remove 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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
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 <thomas.wolf@paranor.ch>
2016-03-14Delegate detection of git repositories to JGitAndre Bossert2-15/+12
This prepares EGit to still properly detect git repositories when JGit change "https://git.eclipse.org/r/#/c/67873/" adds the evaluation of ".git" file with "gitdir" link to worktree and evaluates commondir. Bug: 477475 Change-Id: Id1a54e0efb6fb7334ea4cb4a5507ed3e0bff0f7e Signed-off-by: Andre Bossert <anb0s@anbos.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-03-14Fix NPE in RepositoriesViewPropertyTesterMatthias Sohn1-22/+26
Bug: 489602 Change-Id: If35a2b22aeb34cf15afcf33410d34c7b22308f62 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-03-14Document that hasGerritConfiguration() needs non-null repositoryMatthias Sohn1-1/+3
Change-Id: I5e86c504d304a27ec914492651adae5e4387a731 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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 <matthias.sohn@sap.com>
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 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-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 <markus_keller@ch.ibm.com>
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 <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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 <thomas.wolf@paranor.ch>
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 <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-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 <thomas.wolf@paranor.ch>
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 <matthias.sohn@sap.com>
2016-02-27[staging view] Fixed sort order: added check for "names first" caseAndrey Loskutov1-10/+31
Bug: 487004 Change-Id: I59b0c32c8c077111ebc2e61026961332933e8b54
2016-02-27Do not autofill clone wizard for arbitrary clipboard inputThomas Wolf5-8/+193
The clone wizard would auto-fill also if the clipboard contained arbitrary, non-git related HTTP(S) URLs. This is a regression that was introduced in commit 39f3c68. Auto-fill the clone wizard for HTTP(S) clipboard content not ending in ".git" only if the host is a known git server. A known git server is one from which the user had already successfully cloned a repository over HTTP(S). As a convenience, we provide a very small set of default hosts (git.eclipse.org, github.com, and bitbucket.org). For HTTP(S) URIs that end in .git, we always pre-fill the wizard. Also consider only clipboard content up to the first whitespace (after having removed a potential "git clone" prefix). Formerly, we stopped at the first blank, not general whitespace, and would thus autofill even with multi-line clipboard content like foobar baz .git (No blank in there, just line endings.) Finally, add a few missing braces and remove a spurious trim() call in RepositorySelectionPage. Change-Id: I04e5912b3a28dc911a54dea8255dd64eca58896e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-26Merge "Update Mars orbit repository to R20160221192158"Matthias Sohn5-14/+14
2016-02-26Merge "RepositoriesViewLabelProvider: mark dirty submodules"Matthias Sohn5-29/+116
2016-02-26Update Mars orbit repository to R20160221192158Matthias Sohn5-14/+14
This version fixes signing of Apache httplclient. Change-Id: Ibc15e4d5db755004e821184957a30589e49d013f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-26Check resource.getProject() for null before dereferencing itAndrey Loskutov9-12/+35
Bug: 488538 Change-Id: I886cf1c772aa372fd4bba330541fc8ffb3556198
2016-02-26RepositoriesViewLabelProvider: mark dirty submodulesThomas Wolf5-29/+116
Prepend the dirty indicator "> " to the text label if the submodule has changes. Requires that the RepositoryCache ensures that all repositories are registered under their normalized git directory file name (normalized meaning not containing . or .. components). The RepositoriesViewContentProvider uses a SubmoduleWalk, and that returns non-normalized paths, while the RepositoryMappings always use normalized ones. That results in two different Repository instances for the same git repository; listening for index diff changes on one won't trigger on the other one, and thus labels in the repositories view wouldn't update. Change-Id: Idf4002debdda94b35b278bff8194cde2ecba739c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-25Fix recognition of submodules in folders.Thomas Wolf16-130/+548
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-23Make RepositoryMapping use java.nio.file.PathThomas Wolf2-34/+71
org.eclipse.resources.Path.fromOSString normalizes paths. However, the FileRepositoryBuilder returns paths like /some/path/container/../.git/modules/... . If that get's normalized, we end up with /some/path/.git/modules/... , which defeats the subsequent attempt to relativize the string to ../.git/modules/... . Using java.nio.file.Path, we can avoid this premature normalization, and moreover we can create relative paths in way more cases. Change-Id: I19da4aed3a4a8476f6cb4b1466fa5ab75b095f66 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2016-02-23Fixed egit-4.6 target platform namesAndrey Loskutov2-2/+2
Change-Id: Ibac9fc4c4515310adc34f57d561a3eb676873b5d Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
2016-02-23Remove unnecessary cast to RepositoryMappingMatthias Sohn1-2/+1
The collection mappings is a Collection<RepositoryMapping> so directly assign items in this collection to a variable of type RepositoryMapping and avoid an unnecessary unchecked cast. Change-Id: Idd9a1a58e69fe8a5aa00ec12f66be59d67aef06c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-22Allow filtering of Gitflow feature branches in checkout and track dialogMax Hohenegger7-184/+305
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 investigation: GitSubscriberMergeContextTestThomas Wolf2-0/+52
I can't get that test to fail locally; neither on native OS X nor on a Linux (Ubuntu 15.04) VM. Yet it fails frequently on Hudson. I don't see anything wrong with the test either. Let's include a lot of debug output in an attempt to figure out what's going on. I suggest we do actually merge this, so that we have the extra info the next time it fails. Hopefully that'll give some hints. I couldn't find a thread dump method anywhere, so I wrote my own. Change-Id: Icdd054c5b7f878771046706f615746e3f47e9b4f Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
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-20Gerrit Configuration... is misleading when switching branchesFrank Jakop4-42/+96
Treat "Commit and Push" as Gerrit push for the currently checked out branch when the repository has a gerrit configuration. Bug: 460500 Change-Id: I6eddab11e58a383cd7a9ebe11226f344e97aa324 Signed-off-by: Frank Jakop <frank.jakop@arxes-tolina.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2016-02-19Handle relative paths in RepositoryMapping creatorThomas Wolf2-5/+21
file.getAbsolutePath() with a relative path here resolves against the current working directory of the Eclipse instance. The path is, however, relative to the IContainer being mapped! This causes many of the various occurrences of errors in the log about gone repository mappings, especially those where the absolute path is nowhere near any expected directory. Bug: 456799 Bug: 476011 Change-Id: I9eebf4cb81b7584936f823885db8a5d9340035fd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Back to the top