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

On Mac OS X /tmp is by default a symbolic link.

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

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

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

Change-Id: Iedb54eb9d8396bc3ae66d8754c1527fd9ca655f9

For streams that should not be closed, i.e. don't own an underlying
stream, and in-memory streams that do not need to be closed we just
suppress the warning. This mostly apply to test cases. GC is enough.

For streams with external resources (i.e. files) we add the necessary
call to close().

Change-Id: I4d883ba2e7d07f199fe57ccb3459ece00441a570

This was broken in fe1f1b8f8aba60fdd1ad6f0f72e9c9180978cc60, which
preferred the index over the working tree when both were present.

Change-Id: I97dcf9a088adcbd0187fa7eec9ef34445ce3a981
Signed-off-by: Kevin Sawicki <kevin@github.com>

Whenever a call to JGit returns a Repository the caller should make sure
to call close() on it if he doesn't need it anymore. Since instances of
Repository contain e.g. open FileOutputStreams (for pack files)
forgetting to close the repository can lead to resource leaks.

This was the reason why dozens of the JUnit tests failed on Windows
with "Can't delete file ...." errors. 

In LocalDiskRepositoryTestCase.tearDown() we tried to delete the
repositories we used during tests which failed because we had open
FileOutputStreams.

Not only the obvious cases during Clone or Init operations returned
Repositories, but also the new SubModule API created repository
instances. In some places we even forgot to close submodule repositories
in our internal coding.

To see the effects of this fix run the JGit JUnit tests under Windows.
On other platforms it's harder to see because either the leaking
resources don't lead to failing JUnit tests (on Unix you can delete
files with open FileOutputStreams) or the java gc runs differently and
cleans up the resources earlier.

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

It is not always appropriate to use the .gitmodules file from the
working tree, for example if reading the modules at a specific commit.
And sometimes it is impossible, as in a bare repository.

When using the static factory methods, automatically set up the
appropriate root tree so lazy loading of the config file reads from
the appropriate place. Leave the current behavior of looking in the
working tree as a fallback for the case where walking the index.

Change-Id: I71b7ed3ba16c80b0adb8c5fd85b5c37fd4aef8eb

All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.

Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.

Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.

Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.

Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

This prevents existing entries from being cleared when the
.gitmodules config is saved after the new submodule configuration
is added.

Change-Id: I66841f5e758a7527e2e6e25cf1318e5fea91a909
Signed-off-by: Kevin Sawicki <kevin@github.com>

A '.git' file in a repository's working tree root is now parsed
as a ref to a folder located elsewhere.  This supports submodules
having their repository location outside of the parent repository's
working directory such as in the parent repository's '.git/modules'
directory.

This adds support to BaseRepositoryBuilder for repositories created
with the '--separate-git-dir' option specified to 'git init'.

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

Interpret submodule URLs that start with './' or '../' as
relative to either the configured remote for the HEAD branch,
or 'origin', or the parent repository working directory if no
remote URL is configured

Bug: 368536
Change-Id: Id4985824023b75cd45cd64a4dd9d421166391e10

Adds the following commands:
    - Add
    - Init
    - Status
    - Sync
    - Update

This also updates AddCommand so that file patterns added that
are submodules can be staged in the index.

Change-Id: Ie5112aa26430e5a2a3acd65a7b0e1d76067dc545
Signed-off-by: Kevin Sawicki <kevin@github.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>