Skip to main content
aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.egit.ui/plugin.xml
AgeCommit message (Collapse)AuthorFilesLines
2019-11-16[repo view] Eliminate default handler for paste commandThomas Wolf1-13/+12
Remove the special paste command with its default handler; create a dedicated handler and bind it to the standard paste command instead. Remove the now superfluous key binding. Bug: 495064 Change-Id: Ibcacd226b37bf05f1e46126e277a0f5ef6aab6a1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-11-16[repo view] Bind "Rename Repository Group..." to standard renameThomas Wolf1-38/+43
Use the standard rename for this command handler, and also for the "Rename Branch..." when a Ref node is selected. These show up in Quick Access as "Rename the selected item...", which makes sense, and are bound to F2. Use the special RenameBranch command only when a repository node is selected. Add a key binding for F2 in a special context, and activate it only when a single repository is selected to avoid conflicts with the standard binding. This command shows up in Quick Access as "Rename Branch...". Change-Id: If95b79e83436afaa956593f0c971552eeddc5441 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-11-16[repo view] Introduce repository groupsAlexander Nittka1-3/+111
In order to allow the user to structure repositories a new node type 'group' is introduced. A repository may belong to at most one group. Groups can be created, renamed and deleted; they cannot be nested. If a repository belongs to a group, it is not shown in the tree root. Assignment is done by having repositories selected while creating the group, by drag/drop or via a new context menu entry. CQ: 21019 Bug: 545123 Change-Id: I7bf62760f0f242f2f72db1e674ed26141964fde4 Signed-off-by: Alexander Nittka <alex@nittka.de>
2019-11-12Sort branches in branch selection dialog like in repo viewMichael Keppler1-1/+1
Up to now branches were only sorted by their labels. Instead they must be sorted as branch nodes, since hierarchical layout is not always the same as strictly alphanumerical sorting of the labels. Change-Id: Iee596d51c9645cdd310e39a2e61da4d1d5c9ae97 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-10-26[repo view] Link with selection: immediate reaction, show open editorsThomas Wolf1-19/+3
React immediately when linking with selection is enabled. Track workbench parts even when linking is disabled. When linking is enabled, immediately react on the last selection before the repositories view became active. When the selection inside the view changes react to a FileNode being selected by bringing an already open editor of that file to the front. Activate and correct the already existing test for this. Remove the old LinkHelper. It wasn't used anymore since commit d6cf5241 in 2013. Bug: 409722 Change-Id: I49ebc0b361469f3058348199ff8bd3557d949634 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-10-25[repo view] Do not allow removing submodules from viewAlexander Nittka1-1/+4
Previously the "Remove Repository from View" command was shown in the context menu for submodules, but executing it had no effect. A guard is added preventing the handler from being active. Change-Id: Ib47cd0621ba8666f4e314aba27f8130c1ad874aa Signed-off-by: Alexander Nittka <alex@nittka.de>
2019-10-24[repo view] Ellipses for the add/clone/create commands in view menuThomas Wolf1-11/+17
Also provide command descriptions (for Quick Access) and give the menu entries tooltips. Fix an accelerator conflict between "Clone" and "Create" (both used &C). Change-Id: I7178a5de2aeec5e812830804024e94ef300562aa Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-10-17[repo view] Let "link with selection" be always enabledThomas Wolf1-11/+2
It's actually a normal state toggling command for which a default handler is fine. It didn't have a default handler because it was badly implemented and assumed that the currently active part was the repositories view. Change the handling of all three toggle commands in the repositories view. Let them only toggle their state, don't make them refresh the view. Make the view listen to state changes and refresh if needed. The content provider doesn't need to listen to changes; it has no way to inform the viewer to refresh. Also remove duplicating the state into local boolean variables; use the state's current value instead. Bug: 537958 Change-Id: I2027a64bd6f4e88439e7975b9d3c3eb3d381efef Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-10-12Document repository view menu insertion pointsMichael Keppler1-7/+7
Trying to get an overview of the available menu items in the repository view context menu, I commented available menu items on the rather generically named "repo-X" insertion points. There are no functional changes. I will close the related bug WONTFIX, since all the mentioned groups have multiple items under certain conditions and can easily be grouped differently. Bug: 538491 Change-Id: Ieff7cc7a3e5929283f52ddb6fe5675ed1918749e Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-09-08Fix visibility of Team->Advanced->Create TagThomas Wolf1-1/+3
This menu contribution needs the visibleWhen clause that got replaced in commit 97c96f88, otherwise it will be visible in the context menu of the history view. Bug: 550820 Change-Id: I7b3dd816767bfcf10b5a3b89f4de9257a95e6c5e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-09-08Use an OSGi declarative service instead of IStartupThomas Wolf1-6/+0
Replace the IStartup and org.eclipse.ui.startup extension point by a declarative OSGi service component listening on UIEvents.UILifeCycle.APP_STARTUP_COMPLETE. Bug: 550742 Change-Id: I04ee521810f0aa05f64f24460f07ea5060505dfc Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-08-20Remove duplicate configure fetch/push commandsMichael Keppler1-14/+4
The commands "configure fetch" and "configure upstream fetch" use the same handler and the same label, therefore one of them is superfluous. Remove the one without ".team" in the command id, since ".team" is a convention in the list of command ids in the egit API. Redirect menus and command images to the remaining command id. Bug: 549997 Change-Id: I5f8129670566e2f41051f0f533dcf36947d4dd68
2019-08-15Bind F2 on repo node to rename of current branchMichael Keppler1-6/+24
Add the ability to use F2 directly on the repository node to rename the current branch instead of first having to expand all nodes to the current branch. It would have been possible to use the existing eclipse.ui.edit.rename command (and just to add to the existing activeWhen expression), but that has the bad side effect of the command still being labeled "Rename" in Ctrl-3, when invoked on the repository. Therefore the old rename handler has been attached to the rename branch command instead and a separate key binding has been added to the repositry view, to override the generic F2 rename binding there. Bug: 545290 Change-Id: Idf7fd3fd6f9fba00954d6b7318b11182dcd4cb69 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-07-01Add more command iconsMichael Keppler1-0/+12
* add submodule (repo view context menu) * replace with commit, branch, ref (resource context menu) * compare with commit, branch, ref (resource context menu) Change-Id: I3327b4ae540337b05b07c965e8b22aa9c996df45
2019-03-25Integrate the smart import wizard fragment into the EGit UI bundleThomas Wolf1-0/+8
Move the class into the main bundle now that the EGit baseline is a version that supports smart import. Add the wizard extension in plugin.xml. Move the test class into the EGit UI tests and rewrite it to use a local test repo instead of trying to clone JGit over HTTPS. Remove the smartimport fragment and the ui.importer.tests project. Add the update clause to the p2.inf of EGit UI to ensure that p2 removes the fragment when EGit UI is updated. Also remove the smartimport fragment from the repository, and remove the maven modules. Change-Id: I6b9c3138da25d77995ef0acd9168ddccc3663568 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Handle expected value in property testersThomas Wolf1-181/+47
Derive all EGit property testers from AbstractPropertyTester and use its computeResult() method to match the computed value against the expected value. Replace negations of property tests in plugin.xml by value="false". Change-Id: I5b42653ee7fd60d49aa75cc39250eb30067c6490 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Revert" commandsThomas Wolf1-28/+14
Remove the command from the history view; add the missing checks to the one from the commit editor. Give the command a new regular command id (neither had a category before), and adapt the activation expression in plugin.xml. Bug: 545031 Change-Id: I5322557772c7195dd08d8fa2f7fefb75da20eaf1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Show in History" commandsThomas Wolf1-16/+15
Use the same command id for both the "Team" sub-menu and for the commit editor. Remove the extra command for the commit editor from plugin.xml, but leave the two different handlers. Bug: 545031 Change-Id: If9f530c032b6a7cfe11f90cdc19f1bc00f988b83 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Cherry-Pick" commandsThomas Wolf1-31/+19
Remove the one from the history view, give the one from the commit editor a new command id and a category. Change-Id: I9600b98ed91bd89c0338263dfa7b166b8763daad Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Checkout" commandsThomas Wolf1-39/+22
Use the same command ID for all the different handlers and ensure no two of these handlers are active at the same time. Bug: 545031 Change-Id: If5c7a52d919f19a0442dcb06800602f99bd6684c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Create Tag..." commandsThomas Wolf1-65/+32
Handle commit selections in the general TagActionHandler, too. Delete the two special handlers for the history view and the commit editor, and remove the respective commands. Replace the default handler for the "org.eclipse.egit.ui.team.Tag" command and give it a dedicated handler with an activeWhen expression. Bug: 545031 Bug: 495064 Change-Id: I968fb4c7d577a705c27b0f51884ba63425aa7caf Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify "Create Branch" commandsThomas Wolf1-41/+19
EGit had three different commands for "Create Branch", one in the repositories view, one in the history view, and one in the commit editor. The one from the repositories view was the only one that had a category ID and that thus showed up by default in the key binding preferences. Change that to use one single command with two different handlers, one for RepositoryTreeNodes and one for IRepositoryCommits as used in the history view and in the commit editor. Delete the dedicated handler for the history view, and generalize the other such that it works in either the history view or in the commit editor. The command re-uses the ID from the repositories view command because of bug bug 415382, though I would have liked to introduce a new command ID "org.eclipse.egit.ui.team.branch.create". Bug: 545031 Change-Id: I57f2f6c15e2f7bb796ecb3bc4c790893b094d68c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Remove unused command ID for "Delete Stash..."Thomas Wolf1-11/+17
EGit has two command IDs for deleting stashes. The one from the commit editor's handler had no category, but the other one had no handler and appeared nowhere, because the handler is bound to the standard "delete" command. Use the one with the category for the commit editor's handler. This enables a user to define a key binding for this handler and invoke it in the commit editor via the keyboard. Contrary to the "Apply Stash" case, the handlers from the commit editor and from the repositories view are not similar enough to warrant a code refactoring. Maybe if one made the StashedCommitNode adapt to IRepositoryCommit, but then one has to be careful that no other commands get enabled inadvertently on such nodes. Bug: 545031 Change-Id: I5dd3e0e49746babcb825478d16be0eadab5dfa38 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-21Unify handling of "Apply Stash"Thomas Wolf1-62/+30
EGit had two nearly identical implementations for applying a stash, once for a node in the git repositories view and once for a commit editor. Turns out that the one in the commit editor was general enough to be used in the repositories view, too. Delete that one and replace by the one from the commit editor. However, keep the "public" ID: the ID "org.eclipse.egit.ui.team.stash.apply" had a category and was thus shown by default in the key bindings preference page, whereas the "org.eclipse.egit.ui.commit.StashApply" ID had no category and was thus invisible. Users are thus more likely to already have a key binding for the old ID. Giving the new ID now a category leads to the "Apply Stash" command show up twice in the key bindings dialog because the old ID is not removed from workbench.xmi, even if it is removed from EGit. (That would be bug 415382...) This fixes bug 545031 for the "Apply Stash" command, but not yet for the other commands available in the commit editor. Bug: 545031 Change-Id: Ie667f964c97d67a5b0e4dfcd4231ee567411995b Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-03-13Use an icon for the Stashes menuMichael Keppler1-2/+4
We recently discussed in multiple bug reports that stashing is not as easy to discover (from a UX perspective). Make users more aware of stashing by having an icon for the Stashes sub menu. Change-Id: I11f7d21891085889f5944363c8fa9c1cda23a789 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-03-13Have a description for the Git perspective.Michael Keppler1-0/+3
This is only shown when pressing F2 in the "open perspective" dialog. Nevertheless let us have a perspective description, it might be used at other places in the future. Change-Id: Ib44f010ec872eb97d3135eedd97ee617ef8e8ca5 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-03-09Add filters to Git Repositories ViewAlexander Nittka1-2/+46
Based on the CommonNavigator filtering mechanism, filters for sub-trees (e.g. tags. remotes, references) in the Git Repositories View are added. The intention is to give the user more control over the items displayed in the repositories view (hiding items not permanently needed). This filtering does not allow for restructuring the tree, e.g. moving local branches directly below the "Branches" parent without the intermediate "Local" parent. Bug: 540003 Change-Id: I3f186e6a8c5f03cebf07954f6e9248c887b8d290 Signed-off-by: Alexander Nittka <alex@nittka.de>
2019-02-20Group context menu items correctlyMichael Keppler1-0/+3
Move the "Show in system explorer" to the "group.show" group to not mix it up with the entries from the "group.open" group. Bug:544517 Change-Id: I6bb5b19407805f5de1630197fc806c7c35f2b7c8 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-02-20[history] Handle workspace and non-workspace files alikeThomas Wolf1-29/+2
With compare mode on and the history view filtered to one file, a double click on a commit opens a compare editor for that file. But the behavior for files in the Eclipse workspace and files outside of the Eclipse workspace were different: * IResource (file in workspace): compare against working tree * File (file not in Eclipse workspace): compare against HEAD The context menu also had the same difference. Judging from the (now removed) TODO in CompareWithWorkingTreeHandler comparing against HEAD was just a work-around for not being able to create a compare editor input for plain java.io.Files. Since LocalNonWorkspaceTypedElement enables us to do exactly that, use it and also compare non-workspace files against the working tree. Remove the Compare with HEAD menu command from the history view context menu completely. Remove the handler, too, and simply always use "Compare with Working Tree" instead. "Compare with HEAD" is available anyway by selecting the HEAD commit and another commit, then choosing "Compare with each other". Change-Id: Ic04168432cf64928aa73b81d3cf250f096e74b31 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-02-16Display more icons in egit menu itemsMichael Keppler1-2/+32
The following menu items display an icon now (they did not show an icon before, but all the icon files already existed): * Show Revision Information (in editor ruler) * Show in Editor (repository view) * Rebase Feature (gitflow) * Checkout Feature (gitflow) * Checkout develop (gitflow) * Compare with > Commit * Replace with > Commit All other newly registered command images in this change were visible as icons before already. They were just not bound to the command. That means they were missing in the keys preference page and the Ctrl-3 completion, but not in the egit ui. Change-Id: I6f82ef6c54125cd02a1f61442c5cd0a9c2e9c72f Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2019-02-15Minor formatting fixes in UI plugin.xmlThomas Wolf1-161/+137
Fix formatting of adapter factory and preference page elements. Change-Id: Ide76c1aa2a848ebcf6a80fe164f9e7cf4bccbde4 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2019-02-15CommitFileDiffViewer: better performance for huge commitsTim Neumann1-0/+6
Displaying the list of files changed might still freeze the UI for really huge commits (> 10'000 changed files). Turns out that using a SWT.VIRTUAL table is much faster for this use case. Make the FileDiffLabelProvider safe against being passed null elements. Improve getting icons for the FileDiffs; make sure that already the base images are cached in the ResourceManager. Avoid using EGit's DecorationOverlayDescriptor; it loads the base image's ImageData to determine the size of the base image, and this loading is entirely uncached! FileDiffs are shown elsewhere, too, for instance in the fetch result dialog. Provide an explicit WorkbenchAdapter for these cases. This still uses the potentially expensive DecorationOverlayDescriptor, but the separation opens the way to eventually move the decorating into an asynchronous lightweight decorator, and it's a much less prominent place, too. Move the background loading out of the content provider and into CommitFileDiffViewer; doing this in the content provider confuses the hell out of a virtual table. Do it properly outside of any table-related manipulations. In CommitFileDiffViewer, fix a number of performance problems with selections: * "select all" was very slow; instead of going through the content provider call selectAll() on the SWT table. * ensure setSelection(StructuredSelection.EMPTY) goes through doDeselectAll(). * Avoid expensive preservingSelection() when the selection is huge by clearing it before setInput() if it's known that it cannot re-apply. Disable SWT.MULTI on GTK with SWT versions < 4919 (Eclipse 4.10). Combined with SWT.VIRTUAL it may lead to extended UI freezes because of bug 499850. (No such problem is known on OS X or Windows.) Provide a new context menu action "Copy All Paths". Bug: 544237 Change-Id: Ia4634993246e35d6d79a35f3cfa02c0e8127f2ef Also-by: Thomas Wolf <thomas.wolf@paranor.ch> Also-by: Andrey Loskutov <loskutov@gmx.de> Signed-off-by: Tim Neumann <Tim.Neumann@advantest.com>
2019-01-29New Git Repo wizard should have a descriptionMatthias Becker1-0/+3
Also fix case of an existing text. It should be sentence case. Bug: 543897 Change-Id: I1db0e43e03878393d86397d326a618fea393c33c Signed-off-by: Matthias Becker <ma.becker@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2019-01-04Provide "Show in System Explorer" on working tree nodesMichael Keppler1-0/+43
Adapted version of the same workbench command, which can only deal with IResource based input. Only tested on Windows. Bug: 541278 Change-Id: Ifdf5ac5986aa0e1919f2cde89972537d6d1c2337 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-11-30Avoid triggering unintended commandsThomas Wolf1-52/+70
Commit 56991ad introduced the ability to switch repositories in all EGit views. This works through providing a "fake" selection containing the repository, and all our views reacting when the current selection changes and has a different repository. To avoid creating multiple entries in the Git history view's view history, the code used a RepositoryNode to encapsulate the repository in that selection. However, that had the side-effect of enabling commands from the repository view that should be active only if the real selection is a RepositoryNode. Avoid this by using a different class. It's still a RepositoryTreeNode and thus still compares equal() to a RepositoryNode (which is the criterion to avoid duplicate view history entries in the history view), but since it is not a RepositoryNode, commands are not enabled. For the few cases where command handlers are active on general RepositoryTreeNodes add conditions in plugin.xml to ensure it's not such a new RepositoryVirtualNode. Bug: 541752 Change-Id: Id33727a1adfba44c3bfe781297cbf04032f60458 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-11-21Keywords for all git preference pagesMichael Keppler1-29/+52
Bug: 540769 Change-Id: Ia160517d391547a8567ac12cc7328113e9da3e21 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-10-17Enable "show in history" for staged deleted filesMichael Keppler1-0/+7
For deleted resources, the staging entry contains a path, not a resource. Therefore Path needs to be supported both in the adapter registration as well as in the history page input calculation. Bug: 539723 Change-Id: I4d17462d4ff0fe39693c9cdc16d296004203112d Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-09-27Add support for multi repository selection for switching branchesLuís Copetti1-1/+54
When multiple repositories are selected the Switch To... option will display only the branches that are present in all of the repositories. By clicking in any of them, the user will concurrently switch branches for all the repositories. If the list of branches is to be empty, a disabled menu item will be added to show that no matching branches were found. Change-Id: I0f850baeb94cb8cb4169d8684bb37756b5c0c372 Signed-off-by: Luís Copetti <lhcopetti@gmail.com>
2018-09-23Unify order of branch context menu itemsMichael Keppler1-64/+64
The order of the menu items Merge, Rebase, Reset, Synchronize in the repository view context menu is different, depending on whether the menu is opened on the currently checked out branch or a not checked out branch. This change modifies the context menu for not checked out branches to be more similar to the one for the checked out branch. Bug: 538844 Change-Id: I19687bd5ca08b4eb1fcb5ba5f943bdc2113baf36 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-09-22Git perspective improvementsMichael Keppler1-1/+44
* improve view ratio for repository view: 0.3 instead of 0.5 (so the repositories view only takes a smaller left column, not the complete left half) * have history view as first view in bottom stack, not properties * add view shortcut to git perspective: git repositories view * add file new shortcut to git perspective: new repository wizard * add new action set for git search, which provides a direct git search menu in the top level Search menu, similar to the direct Java search menu * enable search action set in git perspective (e.g. the Search->Git is always visible in that perspective) * enable search action set when one of the git relevant views/parts is active (in any perspective) * add Synchronize view to action set part associations for both git related action sets Bug: 538907 Change-Id: I406fa3fec3f966702fe08652be80a88cea6ae260 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-09-01Reorder reflog view context menuMichael Keppler1-5/+8
* put open in commit viewer to top and have a separator afterwards, since that is the default action * use "Check Out" instead of "Checkout" as in other places Change-Id: I5d04e149e55bdcfddbb36897c2c81fb6653f0084 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
2018-08-06Rename RepositoriesViewLabelProvider to RepositoryTreeNodeLabelProviderThomas Wolf1-1/+1
It's not a label provider for the git repositories view; it is a label provider for RepositoryTreeNodes. (Which happen to be _also_ shown in the git repositories view, but they're also shown and labeled through this class elsewhere.) Change-Id: I5221ba06aaf475b3b577b8ccb2846b62a64331c8 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-08-06Use an asynchronous lightweight decorator in the repositories viewThomas Wolf1-0/+15
In the previous implementation, the label provider produced styled labels that included the decorations. But label providers run in the UI thread, and expensive decorations like a branch state (N commits ahead, M behind) could thus lead to UI blocks. Newly, leverage Eclipse's built-in support. Use a lightweight decorator for RepositoryTreeNode and register it in plugin.xml. Separate out getting labels into a WorkbenchAdapter and adapt the GitAdapterFactory accordingly. (We already created a WorkbenchAdapter there, but first we always created a new one, and second, it always created a RepositoriesViewLabelProvider just to get the label text. That's terribly inefficient and the logic is completely backwards.) Also use ImageDescriptors instead of Images where possible. Factor out the handling of LabelProviderChangedEvent from GitLightweightDecorator into GitDecorator and re-use it in the new decorator for RepositoryTreeNodes. Make the RepositoriesViewLabelProvider a decorating label provider based on a WorkbenchLabelProvider, which uses the singleton RepositoryTreeNodeWorkbenchAdapter to get labels and images. Change the other uses of RepositoriesViewLabelProvider in dialogs to work with the new setup. Adapt git repositories view tests. These often use the label provider to determine expected node labels, and then try to find a node with a matching label. Decorations are now asynchronous, and thus the label returned from the label provider may or may not contain the decoration. Even with waiting for decoration jobs we may end up with the label being determined in the test and the one in the UI being different. The latter may or may not contain the decoration, which makes finding expected nodes a bit difficult. For now, use the TestUtil navigation methods, which just check for containment. This works well, but because some decorations include the repo directory path which in turn includes the test method name, some test methods and even some test repo names had to be changed to avoid false "duplicate nodes" failures. User-visible UI changes from all that: next to none. Three differences I noticed in the default theme on OS X: 1. Decorations all use the default decoration style (light brown), with the exception of the directory paths shown on repository nodes and on working tree nodes. Those are handled specially and use the qualifier style. 2. Decorations in the "File->Import...->Projects from Git->Existing git repositories" page now actually work. 3. Image decorations briefly flicker on a refresh because of the way asynchronous lightweight decorators work. The flickering is due to the repository view being wholly refreshed frequently. On such a refresh, the viewer tries to get a new decorated label, but the decoration isn't available yet. Once it is available, an event is fired, and the viewer updates the label again. For text labels, the new RepositoriesViewLabelProvider contains a work-around, but for images, that method won't work. The only image decorations (so far) are the check markers for the currently checked-out ref. Otherwise, I notice much faster Eclipse startup with the repositories view open and containing some repositories. Bug: 536814 Change-Id: Ifa8279dd6755c57696b8b64e96bc41a1f948aa59 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-08-01History table: let the user define which columns are shownThomas Wolf1-26/+42
Columns in tables cannot be shown/hidden individually. But we can set the width to zero to hide a column. Of course the user can hide and restore columns directly by dragging the column separators, too. Add a "Columns" sub-menu in the view menu where the user can check the columns to be shown/hidden. These modifications are transient; they are not saved or restored when the view is closed or opened, and they do not survive across and IDE restart. This is similar to the "pinned" state of a history view. To permanently change which columns are shown by default, there's a new preference page. Bug: 339796 Change-Id: Ib8daff29b6610eed1397969a203947e5e72b629a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-06-30Move clean menu item before garbage collect menu itemMichael Keppler1-7/+10
This menu item is probably used rather seldom and should not be on the top of the menu. Also enable the clean menu on the working directory tree node. Change-Id: I95506e8577dec90d6c815c2fb8334c0894f71ebe Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de> Bug:536236
2018-06-22History search: use CSS for text field background colorThomas Wolf1-0/+1
Use a CSS class on the text field to set the light red background color when there are no matches. Remove the CSS class to reset the background. This makes the background color changes work as expected with themes that define their own background. Note that changing the background of a text field is supported by SWT currently only on gtk and on Windows. Bug: 532940 Change-Id: Ieb1c6b70a5df9b23c18b501b89379fa9cdeb66fb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-06-13Merge branch 'stable-5.0'Matthias Sohn1-1/+38
* stable-5.0: Prepare 5.0.1-SNAPSHOT builds EGit v5.0.0.201806131550-r Fix merge of wrong patchset of "EGit integration for LFS" Prepare 5.0.0-SNAPSHOT builds EGit v5.0.0.201806131210-r Update documentation for 5.0 EGit integration for LFS Downgrade Apache httpclient to 4.5.2.v20170210-0925 Handle new CommandFailedException when execution of ssh command fails Fix target platform Revert "Update staging view on repository config changes" Update to latest Photon Orbit R20180606145124 Use hash lookup for TreeViewers Prepare 5.0.0-SNAPSHOT builds EGit v5.0.0.201806050710-rc3 Fix AssumeUnchangedOperation not working on directory/project Change-Id: Ideee702514592028c5757b976237f35f4eea32bf Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2018-06-13EGit integration for LFSMarkus Duft1-1/+38
* Register builtin LFS on startup When EGit starts and the lfs bundle (org.eclipse.jgit.lfs) is available register the LFS implementation and check configuration. * Allow install (enablement) of LFS support in Preferences (global) and on the repository (local). * Apply smudge/clean filters where applicable and required. * LFS integration using built-in JGit lfs filters fully works when using Gerrit with lfs plugin using ssh protocol. * Pushing lfs objects over http still fails with 401 response code, this is tracked in JGit bug 535814 Change-Id: I465da0f1c7f88272d3ec0e6545eea582eae631ec Also-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Markus Duft <markus.duft@ssi-schaefer.com>
2018-06-04Do not display "[NO-HEAD]" for empty repositoryThomas Wolf1-1/+1
After a new repository has been created, its "master" branch is an unborn branch. EGit showed "NO-HEAD" in the decorations for this case. This is confusing for novices and looks like something went wrong. The canonical implementation shows after "git init; git status": "On branch master" and "Initial commit". So let's display "master" in this case, too. Reserve the "NO-HEAD" for cases where there is really no HEAD. Also show such a HEAD in the repositories view under "References" and decorate it as "[master] unborn; will be created by commit". Limit showing such a HEAD to the repositories view: the content provider is used in other places where such a HEAD node would only cause confusion or malfunctioning. Use an extension factory to create the content provider for the repositories view; in this way the new behavior can be enabled there only without having to touch all the other places where this content provider is used. Adapt the label provider to handle the new case, and ensure that the history page doesn't get confused and broken if HEAD is such an unborn branch. In the staging view, use the the warning message label above the commit message text area to tell the user that this commit will create the still unborn branch. Bug: 533596 Change-Id: Ifd0547a156f0a5616ce7e032ea8daebd2596f31e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
2018-05-13Enable resource selection for launch variablesMichael Keppler1-0/+19
This allows to specify an argument for the egit launch variables via a built-in resource selector, similar like it works for ${project_loc}. Bug: 534604 Change-Id: I926a9aa63ff4f7847923b2bb72082a323f1e7d59 Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>

Back to the top