This is the format given by the Eclipse legal doc generator [1].

[1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit

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

This adds --match option for glob(7) matchers on git tags to jgit
describe in CLI.

Bug: 518377
Change-Id: I745988d565dd4391e8b3e5a91bbfbae575333819
Signed-off-by: Oliver Lockwood <oliver.lockwood@cantab.net>

In different places (Main, TextBuiltin, CLIGitCommand) we report fatal
errors and at same time want to check for fatal errors in the tests.
Using common API simplifies the error testing and helps to navigate to
the actual error check implementation.

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

Make the default execute() function fail fast on first command printed
"fatal: " to output.

Introduced executeUnchecked() for few tests which wanted to test fatal
output.

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

Signal early command termination due '-h' or '--help' option via
TerminatedByHelpException. This allows tests using
CLIGitCommand differentiate between unexpected command parsing errors
and expected command cancellation "on help" (which also allows
validation of expected/unexpected help messages).

Additional side-effect: jgit supports now git style of handling help
option: any unexpected command line options before help are reported as
errors, but after help ignored.

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

Native git supports "git describe --long". This will enforce returning a
long description of a commit even if a tag is directly pointing to the
commit (in contrast to just returning the tag name as it is now). This
commit teaches JGits DescribeCommand and the describe command in the pgm
package to support "--long".

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

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

The test checks if an error is thrown when trying to create the same tag
for the second time.

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

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

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

CQ: 6385
Bug: 365444
Change-Id: I2d5164cd92429673fe3c37e9f5f9bc565192cc12
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

jgit.storage.dht is a storage provider implementation for JGit that
permits storing the Git repository in a distributed hashtable, NoSQL
system, or other database.  The actual underlying storage system is
undefined, and can be plugged in by implementing 7 small interfaces:

  *  Database
  *  RepositoryIndexTable
  *  RepositoryTable
  *  RefTable
  *  ChunkTable
  *  ObjectIndexTable
  *  WriteBuffer

The storage provider interface tries to assume very little about the
underlying storage system, and requires only three key features:

  *  key -> value lookup (a hashtable is suitable)
  *  atomic updates on single rows
  *  asynchronous operations (Java's ExecutorService is easy to use)

Most NoSQL database products offer all 3 of these features in their
clients, and so does any decent network based cache system like the
open source memcache product.  Relying only on key equality for data
retrevial makes it simple for the storage engine to distribute across
multiple machines.  Traditional SQL systems could also be used with a
JDBC based spi implementation.

Before submitting this change I have implemented six storage systems
for the spi layer:

  * Apache HBase[1]
  * Apache Cassandra[2]
  * Google Bigtable[3]
  * an in-memory implementation for unit testing
  * a JDBC implementation for SQL
  * a generic cache provider that can ride on top of memcache

All six systems came in with an spi layer around 1000 lines of code to
implement the above 7 interfaces.  This is a huge reduction in size
compared to prior attempts to implement a new JGit storage layer.  As
this package shows, a complete JGit storage implementation is more
than 17,000 lines of fairly complex code.

A simple cache is provided in storage.dht.spi.cache.  Implementers can
use CacheDatabase to wrap any other type of Database and perform fast
reads against a network based cache service, such as the open source
memcached[4].  An implementation of CacheService must be provided to
glue this spi onto the network cache.

[1] https://github.com/spearce/jgit_hbase
[2] https://github.com/spearce/jgit_cassandra
[3] http://labs.google.com/papers/bigtable.html
[4] http://memcached.org/

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

Per CQ 3448 this is the initial contribution of the JGit project
to eclipse.org.  It is derived from the historical JGit repository
at commit 3a2dd9921c.

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