Change-Id: I3bbb6da951765d79d77aa955edeac7b5e4da5d8a

Change-Id: I15370d7807c82ee85ed7fdb05061a4baf0a77a68

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>

It's strange that we have that member since it is not so clear
when it it set or not.

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

According to Win32 API, you need to specificy whether a symlink
points to a file or directory. These tests suggests a symlink created
for a file, can actually point to a directory. We can also create the
link before the target exists, so at least in this respect Windows
symbolic links appears to work as POSIX links.

On POSIX systems these tests have no relevance.

Change-Id: Id3991a4fc4333087c6f569acf04f503b0a0f170d

Test that the file mode of a file is the one expected before and after a
checkout. Tests between symlink and file, symlink and folder, symlink
and missing.

Change-Id: If65a85a5667e25103eb9fd328a8723e29de04a1f
Signed-off-by: Axel Richard <axel.richard@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: Ia4c9c7902316bc0a90fb89d8dea9902835c06dfa

Change-Id: I134cfbda47f4d252fec1a16034e2e78b73cd5081

Change-Id: I6b615f0d5da4339f1f23a29bcaeb80f0346f5764

Buck does not create a target directory for the build output, this
is Maven specific and the project unit tests should not rely on it.

Instead follow the pattern used by org.eclipse.jgit.test which is to
create a temporary directory in the system temporary folder, and
configure the Maven surefire plugin to use the target directory.

Change-Id: Iebe5093332343a90f51080614e083aac0d29c26d

DirCacheCheckout had a bug when the parentdirectory of a worktree was a
symlink. DirCacheCheckout was deleting those symlinks under certain
conditions. This was fixed in I81735ba0394ef6794e9b2b8bdd8bd7e8b9c6460f
without a test because previously it was hard to setup tests containing
symlinks.

BUG: 412489
Change-Id: I2513166af519d6fc01d1eae3976ad6cff6f98530
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

The most important difference is that in Java7 we have symbolic links
and for most operations in the work tree we want to operate on the link
itself rather than the link target, which the old File methods generally
do.

We also add support for the hidden attribute, which only makes sense
on Windows and exists, just since there are claims that Files.exists
is faster the File.exists.

A new bundle is only activated when run with a Java7 execution
environment. It is implemented as a fragment.

Tycho currently has no way to conditionally include optional features
based on the java version used to run the build, this means with this
change the jgit packaging build always needs to be run using java 7.

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