To prevent potential resource leak.

Change-Id: I3f4af9037c9d26ec575b529ab66066365ab918a5
Signed-off-by: David Pursehouse <david.pursehouse@sonymobile.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

Note the the settings are slightly less restrictive for test bundles.
-Also cleanup a couple of malformed javadocs
-Update compiler warnings/errors to include default values from Juno
-We now flag diagnosed null dereference as error. We didn't do that
 earlier because of some false positives.

Change-Id: I58386d63164e65d3d8d1998da3390d99bdc7381a
Signed-off-by: Chris Aniszczyk <zx@twitter.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>

Change-Id: I3b54cb9f73cb433c71a441a11ddc74cfecdaa1dc

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: Ia9a3c9f4728e13d1e62f530b1d843d09afb4eb42
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Change-Id: Iec8cd032d8d659a896d909f9094f76b7d35147e6
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Change-Id: Ia935720fc9c09b427abb84be038c4dc74610850c
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Change-Id: If41e5a9ab37533cce10ea1c1925d7bd3ece586ea
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Bug: 321237
Change-Id: I5c4753f7b99d0be002b32e403f5dfff9353c57b0
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Bug: 321237
Change-Id: I605da8150048158d918c577ef8ca4f6edbed0133
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Adds the initial project and a GitInitTask.

Bug: 321237
Change-Id: I06b94e0b42b20ecf51f86845e47d49913f3513c4
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>