When run under Buck the repository paths may be relative.  Request
an absolute path to construct the URI, as relative paths are not
supported in file:// style URIs.

Change-Id: I85470d1db2f4e80cba30f1559c0d99bdfa8ac410

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

/tmp is a symbolic link and some tests break when the path
gets canonicalized by JGit or Jetty. Allow Jetty to serve
symlinks by setting init parameter "aliases" to true [1].

[1] http://wiki.eclipse.org/Jetty/Howto/How_to_serve_symbolically_linked_files

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

Currently, the offset can only be retrieved by ObjectId or iterating all
of the entries. Add a method to lookup the offset by position in the
index sorted by SHA1.

Change-Id: I45e9ac8b752d1dab47b202753a1dcca7122b958e

Change-Id: I0ec1f17a88bc14f22c10f9bc8d6f5b5118410e3a

/tmp is a symbolic link and some tests break when the path
gets canonicalized by JGit or Jetty. Allow Jetty to serve
symlinks by setting init parameter "aliases" to true [1].

[1] http://wiki.eclipse.org/Jetty/Howto/How_to_serve_symbolically_linked_files

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

I was seeing output like this while running The BFG:

Updating references:    200% (374/187)

...issue sneaked in with 5cf53fda I think.

The update call is also moved to the end of the loop, as update() is
only supposed to be called after work has been done ("Denote that some
work units have been completed").

Change-Id: I1620fa75be16dc80df44745d0e123ea512762e31
Signed-off-by: Robin Stocker <robin@nibor.org>

`pwd`/target is only valid in Maven Reactor builds where Maven
has moved into the project directory and created a target for
the build output. Most other build systems do not use "target"
and may not even perform a directory change between test suites.

Rewrite LocalDiskRepositoryTestCase's temporary directory code
to use the system specified location and create new unique names.
This prevents fixes between concurrently running tests and allows
the caller to specify the root using java.io.tmpdir.

Update the surefire command lines to use target within each project as
the system temporary directory during unit testing, preventing JGit's
own test suite from writing to /tmp or somewhere like C:\tmp.

Change-Id: I9e8431f6ddfc16fee89f677bcce67c99cfb56782

Bug: 406722
Change-Id: I555fb366ee64d885de2a71a67cf00833f4c62561

Change-Id: I8ced7098da5b345fd9af2fdfafd1ef6a44ccee0d

Change-Id: Ib6ee3a2874a7e2240aa68f4ac32d00c4d1fab5ae
Signed-off-by: Chris Aniszczyk <zx@twitter.com>

Instead of re-reading all refs after each update, execute
the deletes first, then read all refs once and perform
the check for conflicting ref names in memory.

Change-Id: I17d0b3ccc27f868c8497607d8e57bf7082e65ba3

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

Only on Windows the rename operation which renames temporary Packfiles
(and index-files and bitmap-files) sometime fails. This happens only
when renaming a temporary Packfile to a Packfile which already exists.
Such situations occur if you run GC twice on a repo without modifying
the repo inbetween.

In such situations there was bug in GC which led to a corrupted repo
whithout any packfiles anymore. This commit fixes the problem by
introducing a utility method which renames a file and throws an
IOException if it fails. This method also takes care to repeat a
failing rename if our FS class has found out we are running on a
platform with a unreliable File.renameTo() method.

I am searching for a better solution because even with this utility
method in hand a GC on a already GC'ed repo will fail on Windows. But
at least with this fix we will not produce corrupted repos anymore.

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

With JGit it is possible to write reflog entries where new objectid and
old objectid is null. Such reflogs cause FileRepository GC to crash
because it doesn't expect the new objectid to be null. One case where
this happened is in Gerrit's allProjects repo. In the same way as we
expect the old objectid to be potentially null we should also ignore
null values in the new objectid column.

Change-Id: Icf666c7ef803179b84306ca8deb602369b8df16e

This breaks all existing callers once. Applications are not supposed
to build against the internal storage API unless they can accept API
churn and make necessary updates as versions change.

Change-Id: I2ab1327c202ef2003565e1b0770a583970e432e9