Bug: 443006
Change-Id: I40b1eb044fa2d9e6c5d4b956c17e32ca6c1bd39f
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>

The aim of this change is to place all commits of a branch on the same
lane and commits of other (side) branches on different lanes.

The algorithm treats first parents of a commit specially by placing them
on the same lane as the commit itself. When a commit is the first parent
of multiple children it could be placed on any of these children's
lanes. In this case it is placed on the longest child lane, as this is
usually the lane of the branch the commit actually was made on.

Other (non-first) parents are placed on new lanes. This creates a layout
that should make it easier to see branches and merges and follow linear
branch histories.
This differs from the previous approach, which sometimes plotted the
commits of a side branch on the same lane as the base branch commits and
further commits on the base branch appeared on a different lane.
This made the base branch appear as if it was the side branch and
the side branch appears to be the base branch.

In addition to lane assignment, also the plotting code changed to start
drawing a branch lane from the commit where it forks out. Previously it
started only when the first commit on the branch appeared.

Active lanes are continued with every commit that is processed.
Previously lanes were only continued when the next commit on the lane
was encountered. This could produce (temporarily) dangling commits if
the next commit on the lane was not processed yet.

CQ: 8299
Bug: 419359
Bug: 434945
Change-Id: Ibe547aa24b5948ae264f7d0f56a492a4ef335608
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Child commits always have a lane assigned when their parents are
processed, so this code is no longer necessary.

Children only assign themselves to parents in
PlotCommitList.setupChildren(), which is called from enter(), when the
child is processed. If the child leaves enter() it should always have a
lane assigned. As a result of this, when processing a parent, all its
known children already have lanes assigned. If the underlying RevWalk
emits a parent before one of its children (which it should not do), the
parent does not know of the child emitted later, because setupChildren()
has not been called for the child yet. So even in this case, no child
without a lane is encountered when processing a (parent) commit.

Change-Id: I982adc5c114370ecfd699d96221a76463de900ca
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

This also properly removes the newly determinded lane position from the
freePositions set in handleBlockedLanes(). closeLane() does only recycle
active lanes, to avoid recycling lanes twice.

Change-Id: Icd019fcf7974441ed05686bb61d6de4e8bf4ab7c
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Using the lane position and other data for equals/hashCode is not
useful.

Change-Id: I7af151d8a84544a77a486474c8ac71dd80090c66
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>

Sometime the new commit is no allocated onto a new lane leading to
the commit being drawn on the wrong branch and something that looks
like a merge.

The drawback is that this also changes existing valid graphs.

Bug: 368927
Change-Id: Ic8a8247c8a53be802c1be83850ed766b902ca646

Use Integer.intValue to explicitly convert to an int

Change-Id: I1135ed01af4e274b26d6b07d1a50f48ef0a30d91
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Use Integer, Character, and Long valueOf methods when
passing parameters to MessageFormat and other places
that expect objects instead of primitives

Change-Id: I5942fbdbca6a378136c00d951ce61167f2366ca4

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

There was a bug in history rendering which caused jgit to use too
many lanes in case lanes get repositioned. Looking at commit
90c11cbaeb in JGit was one example. Vadim
Dmitriev found the problem and the solution.

Bug: 365460
Change-Id: I6024265b7a593dcfd4fc612d0baf6652a0092ff4
Also-by: Vadim Dmitriev <dmgloss@mail.ru>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

There was the possibility that during history rendering we draw a lane
"trough" a passed commit. Vadim Dmitriev found that out in bug 335818. 
I added the needed check to that block of code where it was missing.

Bug: 335818
Change-Id: Ic944193b2aca55ff3eb0235d46afa60b7896aa0f
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

There was the possibility that during history rendering we draw a lane
"trough" a passed commit. Vadim Dmitriev found that out in bug 335818. 
I added the needed check to that block of code where it was missing.

Bug: 335818
Change-Id: Ic944193b2aca55ff3eb0235d46afa60b7896aa0f
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

In PlotCommitList.enter() commits are positioned on lanes for visual
presentation. This implementation was buggy: commits without
children (often the starting points for the RevWalk) are not positioned
on separate lanes.

The problem was that when handling commits with multiple children
(that's where branches fork out) it was not handled that some of the
children may not have been positioned on a lane yet. I fixed that and
added a number of tests which specifically test the layout of commits
on lanes.

Bug: 300282
Bug: 320263
Change-Id: I267b97ecccb5251cec54cec90207e075ab50503e
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

The strings are externalized into the root resource bundles.
The resource bundles are stored under the new "resources" source
folder to get proper maven build.

Strings from tests are, in general, not externalized. Only in
cases where it was necessary to make the test pass the strings
were externalized. This was typically necessary in cases where
e.getMessage() was used in assert and the exception message was
slightly changed due to reuse of the externalized strings.

Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>

As discussed on the egit-dev mailing list, we prefer not to have
trailing whitespace in our source code.  Correct all currently
offending lines by trimming them.

Change-Id: I002b1d1980071084c0bc53242c8f5900970e6845
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This allows SwingGraphPanes to be reused by simply clearing and
re-filling. Requires RevObjectList initialization to not call clear()
from its constructor, because this will lead PlotCommitList.clear()
to be called before all variables have been initialized.

Change-Id: I14a07124441b58cd88c67da088ba52ef9c30b043
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Per CQ 3448 this is the initial contribution of the JGit project
to eclipse.org.  It is derived from the historical JGit repository
at commit 3a2dd9921c.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>