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

org.eclipse.jgit.lib.Repository class is an example of the API which
should be written with Java 8 java.util.Optional<T> type. Unfortunately
this API is already released and widely used. The good clients are
currently doing their best with checking return values for null and bad
clients do not know how bad their code is.

I've tried not to change any logic and to be as less intrusive as
possible. Most of the JGit code was well prepared to this, only few
classes needed some smaller fixes.

This change fixes all compiler errors in JGit and replaces possible
NPE's with either appropriate exceptions, avoiding multiple "Nullable
return" method calls or early returning from the method.

Because annotating getDirectory() and getFS() as Nullable would cause
lot of additional changes in JGit and EGit they are postponed.

Change-Id: Ie8369d2c9c5fac5ce83b3b1b9bc217d7b55502a3
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>

A few classes such as Constanrs are marked with @SuppressWarnings, as are
toString() methods with many liternal, but otherwise $NLS-n$ is used for
string containing text that should not be translated. A few literals may
fall into the gray zone, but mostly I've tried to only tag the obvious
ones.

Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590

If a client attempts to create a branch that already exists on the
remote side, tell them "already exists" rather than repeat lots of
information about the reference. Previously the error looked like:

  ! [remote rejected] tags/1.3.1 -> 1.3.1 (Ref Ref[refs/tags/1.3.1=e3857ee05...] already exists)

Now it will simply say:

  ! [remote rejected] tags/1.3.1 -> 1.3.1 (already exists)

Change-Id: I96fc67ca8b650052de6e662449a3c5bc8bbc010b

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>

Previously only certain values were copied over which caused
divergence in behavior between the JGit command and corresponding
CGit command.

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

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

Change-Id: I113bcf82c6292db5269271f799d09c80acc40bcd

Each time getConfig() is called on FileRepository, it checks the
last modified time of both ~/.gitconfig and $GIT_DIR?config.  If
$GIT_DIR/config appears to have been modified, it is read back in
from disk and the current config is wiped out.

When mutating a configuration file, this may cause in-memory edits
to disappear.  To avoid that callers need to avoid calling getConfig
until after the configuration has been saved to disk.

Unfortunately the API is still horribly broken.  Configuration should
be modified only while a lock is held on the configuration file, very
similar to the way a ref is updated via its locking protocol.  But our
existing API is really broken for that so we'll have to defer cleaning
up the edit path for a future change.

Change-Id: I5888dd97bac20ddf60456c81ffc1eb8df04ef410
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The need for branching becomes more pressing with pull
support: we need to make sure the upstream configuration entries
are written correctly when creating and renaming branches
(and of course are cleaned up when deleting them).
This adds support for listing, adding, deleting and renaming
branches including the more common options.

Bug: 326938
Change-Id: I00bcc19476e835d6fd78fd188acde64946c1505c
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>