Fix endless loop of GenerateHistoryJob

The GenerateHistoryJob was scheduled over and over when the following
precondiations were met:

 - The preference "Team > Git > History > Maximum number of commits to 
   show" has to be set to a numer smaller than the number of commits
   in a repository
 - The history of the repository is fully loaded into the History view
 - The user scrolls down to the end or
 - The user selects a reference which is not yet loaded into the 
   History view

Scrolling triggers the event listener added in the constructor of 
CommitGraphTable (This is done to implement incremental loading).
The event listener calls the method loadItem of GitHistory Page to load
a given commit specified by its index. This method asks the 
GenerateHistoryJob if the commit is less than BATCH_SIZE / 2 away from 
the end, and if so, triggers a new GenerateHistoryJob.

After loading the commits the GenerateHistoryJob wrongly computed the
value of the incomplete variable. It did not check if all commits of 
the history were loaded. Because of that the updateUI method did render
the UI again leading to another call of the event listener above.

This commit adds a check if all commits are loaded. 
This is unfortunately not easily done with the SWTCommitList.

So we check if no new commits were loaded in the current invocation of 
the GenerateHistoryJob and in that case step out of the loop before 
the check for incomplete is done. Then the method updateUI in 
GenerateHistoryJob will not render the UI again and not start the 
endless loop anymore.

But the updateUI method has to render the UI once more after all 
commits are loaded. This is ensured by the new field
forcedRedrawsAfterListIsCompleted.

The case that a certain commit should be selected but is not found is 
handled differently. The UI is not drawn again, but the incomplete
warning is updated.

Bug: 425691
Change-Id: Ice8c59d537156a52acb80c8e004e838e279cdbe3
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Allow to create configuration entries containing dots

This allows to e.g. persist a configuration entry
[branch "2.0.0/master"]
	foo = bar
by specifying key "branch.2.0.0/master.foo" and value "bar".

Bug: 382931
Change-Id: I773980334771b3abef3c9beafbb9813627a79a65
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
Fix "Git Tree Compare" not showing folders that don't exist in workspace

WorkbenchTreeContentProvider had a serious problem in that it only
descended into folders which existed in the workspace. The reason for
that was that it used getChildren of its base class
WorkbenchContentProvider.

For example, when the base (workspace) version had these files:

  a
  b/1

And compare version (e.g. Git Index) had these:

  a
  b/1
  c/1

The "c/1" file should be shown as "deleted" in the view. The problem was
that the "c" folder was not contained in the workspace and so the
content provider never included "c/1". It did include deleted files
whose parent folder was known, but not others.

This could maybe have been fixed by introducing artificial folder nodes
(implementing IWorkbenchAdapter) in such a situation (but only for the
special case above).

Instead, this change unifies the workbench with the PathNode content
provider code. Care was taken to keep the appearance by using
WorkbenchLabelProvider for container nodes and continuing to work with
IFile where possible. The tree construction was also simplified.

Bug: 390886
Change-Id: I726c41f7073820cf80030cc59feabb5b4b033e4d
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
[stagingView] Store children for tree nodes instead of scanning

Before, every time getChildren was called (for each node), all files and
folders were scanned to find the children. The more tree nodes there
are, the more this hurts, as the complexity is quadratic.

Bug: 420825
Change-Id: I16beb6c8caae17b53c4e3ad1f5ddb672f9e96a59
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
[stagingView] Store IFile/IContainer for entries

Instead of calculating the resource on each access, calculate them once
and store them in a field. With 4000 unstaged changes in a test
repository, this brought down the time to expand all elements from 3
seconds to 500-800 ms.

Maybe getting the resources could be made faster by not using
findFilesForLocationURI/findContainersForLocationURI, but instead going
through the projects of the repository and using getFile/getFolder and
only falling back to the above in case nothing is found.

Bug: 420825
Change-Id: I86f0e09fad54d63e7e76ae3541178ae80c867144
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
[stagingView] Improve performance of switching presentation

On a test repository with 4000 changed files, switching between
presentations was 6 seconds before, 1 second after this change.

One problem was that expanding the previously expanded elements was
unnecessarily done when switching presentations.

Also, the refresh was done twice because run() is also called for the
deselected action. See bug 422910 about improving the documentation of
IAction.AS_RADIO_BUTTON.

Bug: 420825
Change-Id: Ie27f15b7a6eb4146f874312a3a6431cf52d5d4b2
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix  SWTExeption: Widget is disposed in StagingView

Bug: 427708
Change-Id: I0f848bfa9443c6d395b9821a1e55a47d03c3d1d6
Add ability to squash commits directly from the history view.

This adds a new menu item Modify > Squash to the context menu
of the history view. It can be used to squash multiple (contiguous)
selected commits into one, prompting for a commit message as well.

An error will be displayed if the selected commits cannot be reached
from the current HEAD commit. This is done so as to avoid the need
to checkout another commit automatically before executing the squash
procedure.

The "Modify" sub-menu is chosen so that new menu items (such as
"Reword" or "Edit") can be added to it rather than the history
context menu directly.

CQ: 7906
Bug: 316521
Change-Id: Ib725899074282027d7542c2ac8bc2c5a9a01da72
Signed-off-by: Maik Schreiber <blizzy@blizzy.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>