Fix reading past FileTreeIterator EOF in FileTreeIteratorJava7Test

Stepping past the '.git' entry with `fti.next(1)` is unnecessary and in
fact a bug, as the subsequent access to FileTreeIterator is past it's
end-of-file - it has only 1 valid entry ('link').

This bug is only visibly exposed in certain environments depending on the
(unguaranteed) return order of `java.io.File.listFiles()`. On my box
FileTreeIteratorJava7Test would fail consistently for these 3 tests:

* testSymlinkActuallyModified
* testSymlinkNotModifiedThoughNormalized
* testSymlinkModifiedNotNormalized

They all failed in the same way:

testSymlinkActuallyModified(org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test)  Time elapsed: 0.063 sec  <<< ERROR!
org.eclipse.jgit.api.errors.JGitInternalException: /home/roberto/development/jgit/org.eclipse.jgit.java7.test/target/jgit_test_9202429389985749040_tmp
/tmp_807992722429349842/.git (Is a directory)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:146)
        at org.eclipse.jgit.treewalk.FileTreeIterator$FileEntry.openInputStream(FileTreeIterator.java:210)
        at org.eclipse.jgit.treewalk.WorkingTreeIterator.readContentAsNormalizedString(WorkingTreeIterator.java:984)
        at org.eclipse.jgit.treewalk.WorkingTreeIterator.contentCheck(WorkingTreeIterator.java:924)
        at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:860)
        at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:815)
        at org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test.testSymlinkActuallyModified(FileTreeIteratorJava7Test.java:198)

Theses tests are all working with a small repo that has just two entries:
'.git' and 'link' (a symbolic link that's being tested on). `listFiles()`
is called by FileTreeIterator to get a preliminary list of FileEntry
objects:

https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java#L139

Whether your tests appeared to pass or fail was dependent on the returned
order of files from `listFiles()`:

* ['.git', 'link'] - PASS (Eclipse Hudson appears to get this ordering)
* ['link', '.git'] - FAIL (My env, Ubuntu 14.04/Java 1.7.0_55)

The tree-iterator passes the resulting `FileEntry`s to it's init() method:

https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java#L639-L665

... where a count of valid entries is made (`entryCnt`), the 'invalid'
entries (like'.git') being left in the hinterland of the `entries` array.
The rearrangement in the entries array for our tests looks like this:

* ['.git', 'link'] -> ['link', 'link']
* ['link', '.git'] -> ['link', '.git']

In both cases, `entryCnt` is set to 1, meaning that the _valid_ portion of
the iterator is the same (ie ['link']), but that the portion after EOF,
which we reach by calling `fti.next(1)`, is _different_ depending on your
environment. The entry used by the iterator at that point will be either
'link' (if you're lucky) or '.git', which will blow up the test.

Note that somewhat ironically, the 'self-check' assertions don't catch
this bug, as 'path' data is only parsed _before_ EOF - so
`fti.getEntryPathString()` returns the string "link" (and the assertion
passes) regardless of whether you're about to read the '.git' entry or not.

Change-Id: Ie58a7bc76b740ee52881ebf555564a74379028d6
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
PlotCommitList: Refactor lane creation and position allocation

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>
PlotCommitList: Remove handling of children that have no lane yet

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>
Improve layout of branches in the commit graph

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>
Fix for reflog corruption caused by multiline message

If a client passes a multiline message as argument to ReflogWriter.log()
the Reflog gets corrupted and cannot be parsed. ReflogWriter.log() is
invoked implicitly from various commands such as StashCreate, Rebase and
many more. However the message is not always filtered for line feeds.

Such an example is the StashCreateOperation of EGit which passes
unchecked user input as commit message. If a multiline comment is pasted
to the stash create dialog, the reflog gets corrupted.

ReflogWriter now replaces line endings in log message with spaces.

Bug: 435509
Change-Id: I3010cc902e13bee4d7b6696dfd11ab51062739d3
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Allow to include untracked files in stash operations.

Unstashed changes are saved in a commit which is added as an additional
parent to the stash commit.
This behaviour is fully compatible with C Git stashing of untracked
files.

Bug: 434411
Change-Id: I2af784deb0c2320bb57bc4fd472a8daad8674e7d
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
Merge "Fix reading past FileTreeIterator EOF in FileTreeIteratorJava7Test"
Adds a callAsMap() function to LsRemoteCommand.

The call() function of LsRemoteCommand returns Collection<Ref>, while its
internal is using Map<String, Ref> all the time. Sometimes the map is much more
useful to the caller so add a callAsMap() function to keep the API
compatibility.

Change-Id: Icb96b71277d5e2de59872aa777352dedc048c4e3
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Merge "Adds a callAsMap() function to LsRemoteCommand."
Update Luna target platform to Orbit release R20140525021250

Change-Id: Id46d74e9b11b2a7ea78d17b8bc12c3ad027723f1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Remove a bit of repetition and casting in PackFileTest

PackFileTest lives in o.e.j.internal.storage.file, so I think it's OK for
it to acknowledge the existence of FileRepository in order to avoid some
unnecessary casting, and probably nicer to avoid the repetition too.

Change-Id: I0de592a32f6178e6d6bf114848101e185b3111a1
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
Fix authentication type names broken by 0b5441a8

0b5441a8 introduced an enum for authentication types and changed the
case of digest and basic authentication type names to all uppercase.
This broke digest authentication at least when using Gerrit as the git
server. 

According to RFC2617 [1] "Basic" and "Digest" is the literal to be used
in authentication headers and not "BASIC" [1] and "DIGEST" [2].
According to RFC4559 "Negotiate" [3] is used for SPNEGO based
authentication.

[1] http://tools.ietf.org/html/rfc2617#page-5
[2] http://tools.ietf.org/html/rfc2617#page-8
[3] http://tools.ietf.org/html/rfc4559#page-3

Bug: 435866
Change-Id: I6173aff9352d7def225cafe2d73e5176ad40dff0
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Unit test for the updating behavior in RepoCommand API.

When update the manifest against a bare repository, RepoCommand will replace
every existing content from the repository with contents populated from the
manifest. Added note for that and a unit test to make sure this behavior.

Change-Id: I1d5960e84bca5aa2a4e86f424d2ddd4197894cdc
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Merge "Unit test for the updating behavior in RepoCommand API."
Remove unused import

Change-Id: I6f59539350ab28605e2e1fe1f30354cd68aa7740
Signed-off-by: Dani Megert <Daniel_Megert@ch.ibm.com>
JGit v3.4.0.201405281120-rc2

Change-Id: Ifd376f58cf867fc84d39582c49e971d998abf63d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Prepare post 3.4.0 RC2 builds

Change-Id: Id8d784ba7b0aba7c6a00f459bf1ac54c1d36d061
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Enable NLS / TranslationBundle to be used in OSGi

TranslationBundle#load() used to load resource bundles through
ResourceBundle#getBundle() without explicitly specifying a class loader.
In this case, the class laoder of the calling class (TranslationBundle
here) is used. This approach fails in runtime environments like OSGi
where there are multiple class loaders.

This change enables loading resource bundles in multi class loaders
environments. The fix is to pass the class loader of the
TranslationBundle-derived class to ResourceBundle#getBundle().

Bug: 436232
Change-Id: I39db61e012dc93ebf388a71bf6088a3310a22bac
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Make JavaDoc validator happy by declaring GitAPIException on callAsMap

Change-Id: I9caa559a3d4eb0ec93d90cf1e18aed785ef85a84
blame: Un-break isFile check in tree walk

Originally, blame's walk to find a scapegoat to blame for a file
walking backward from a commit used the test

	treeWalk.getFileMode(0).getObjectType() != OBJ_BLOB

to throw out gitlink (submodule) entries.  Later, 52500d3264d2 (blame:
Micro optimize blob lookup in tree, 2014-04-17) changed that test to

	(treeWalk.getRawMode(0) & TYPE_FILE) != TYPE_FILE

These checks are not the same, though: the older test accepts files
and symlinks, while the newer one accepts files, symlinks, and gitlink
(submodule) entries.  This is particularly broken in the submodule
case --- trying to parse the referred-to commit as a blob produces

	caught an exception: GET /gerrit/+blame/master/plugins/reviewnotes HTTP/1.1
	org.eclipse.jgit.errors.MissingObjectException: Missing blob 61702414c046dd6b811c9137b765f9db422f83db

Stick to just (possibly executable) files instead.  Symlinks are not
line-oriented data so blame on a symlink is not likely to be useful.

A quick grep for '& TYPE_' doesn't find any other instances of this
bug.

Change-Id: Iebcc91f1bee3c91adda51dccd6372e8302bf23fe
Signed-off-by: Jonathan Nieder <jrn@google.com>