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>

Factor out the test parameterization to use both connection factories
into a common super class and use it in more tests.

This made HttpClientTests.testV2HttpSubsequentResponse() fail for
Apache HTTP. The test used the pattern

  - create POST connection
  - setDoOutput(true)
  - connect()
  - write output stream
  - get & read input stream

This pattern is never used in JGit, which actually calls connect() only
in one case in LFS, and that's on a HEAD request.

The above pattern works on JDK, but fails on Apache HTTP because with
Apache HTTP a connect() actually executes the full request including
writing the entity. To work with Apache HTTP, the pattern would need
to be

  - create POST connection
  - setDoOutput(true)
  - write output stream
  - connect()
  - get & read input stream

which is fine for both. JDK connects implicitly in getOutputStream()
and treats the later explicit connect() as a no-op, and Apache works
because the entity is written when connect() is called.

Because JDK connects implicitly on getOutputStream(), the following
pattern also works with JDK:

  - create POST connection
  - setDoOutput(true)
  - write output stream
  - get & read input stream

Support this with Apache HTTP too: let getInputStream() execute
the request if it wasn't executed already.

Remove explicit connect() calls from test code, since JGit doesn't do
those either.

Change-Id: Ica038c00a7b8edcc01d5660d18e961146305b87f
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Change-Id: Iaf339ae739689d4528a079776d6e945ba9006368
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Its implementation contains

		} catch (IOException e) {
			// Legacy API, assume error means "no"
			return false;
		}

Better to use ObjectDatabase#has, which throws IOException to report
errors.

Change-Id: I7de02f7ceb8f57b2a8ebdb16d2aa4376775ff933
Signed-off-by: Jonathan Nieder <jrn@google.com>

Since the introduction of generic type parameter inference in Java 7,
it's not necessary to explicitly specify the type of generic parameters.

Enable the warning in Eclipse, and fix all occurrences.

Change-Id: I9158caf1beca5e4980b6240ac401f3868520aad0
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Set missingOverrideAnnotation=warning in Eclipse compiler preferences
which enables the warning:

  The method <method> of type <type> should be tagged with @Override
  since it actually overrides a superclass method

Justification for this warning is described in:

  http://stackoverflow.com/a/94411/381622

Enabling this causes in excess of 1000 warnings across the entire
code-base. They are very easy to fix automatically with Eclipse's
"Quick Fix" tool.

Fix all of them except 2 which cause compilation failure when the
project is built with mvn; add TODO comments on those for further
investigation.

Change-Id: I5772061041fd361fe93137fd8b0ad356e748a29c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

After creating a Transport instance callers should always call
its close() method. Use AutoCloseable to document this idiom
and allow use of try-with-resources.

Change-Id: I0c6ff3e39ebecdd7a028dbcae1856a818937b186

The Repository class provides only one method to look up a ref by
name, getRef.  If I request refs/heads/master and that ref does not
exist, getRef will look further in the search path:

 ref/refs/heads/master
 refs/heads/refs/heads/master
 refs/remotes/refs/heads/master

This behavior is counterintuitive, needlessly inexpensive, and usually
not what the caller expects.

Allow callers to specify whether to use the search path by providing
two separate methods:

- exactRef, which looks up a ref when its exact name is known
- findRef, which looks for a ref along the search path

For backward compatibility, keep getRef as a deprecated synonym for
findRef.

This change introduces findRef and exactRef but does not update
callers outside tests to use them yet.

Change-Id: I35375d942baeb3ded15520388f8ebb9c0cc86f8c
Signed-off-by: Jonathan Nieder <jrn@google.com>

This change implements the http connection abstraction with the help of
org.apache.http.client.HttpClient. The default implementation used by
JGit is still the JDK HttpURLConnection. But now JGit users have the
possibility to switch completely to org.apache.httpclient. The reason
for this is that in certain (e.g. cloud) environments you are forced to
use the org.apache classes.

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

/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>

/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>

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: Ief195fb5c55f75172f0428fdac8c8874292ae566

Eclipse has some problem re-running single JUnit tests if
the tests are in Junit 3 format, but the JUnit 4 launcher
is used. This was quite unnecessary and the move was not
completed. We still have no JUnit4 test.

This completes the extermination of JUnit3. Most of the
work was global searce/replace using regular expression,
followed by numerous invocarions of quick-fix and organize
imports and verification that we had the same number of
tests before and after.

- Annotations were introduced.
- All references to JUnit3 classes removed
- Half-good replacement for getting the test name. This was
  needed to make the TestRngs work. The initialization of
  TestRngs was also made lazily since we can not longer find
  out the test name in runtime in the @Before methods.
- Renamed test classes to end with Test, with the exception
  of TestTranslateBundle, which fails from Maven
- Moved JGitTestUtil to the junit support bundle

Change-Id: Iddcd3da6ca927a7be773a9c63ebf8bb2147e2d13
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Introduce a http test bundle to make this functionality available for
EGit tests. A simple http server class is provided. The jetty version
was updated to a version that is also available via p2 (needed in EGit
UI tests).

Change-Id: I13bfc4c6c47e27d8f97d3e9752347d6d23e553d4
Signed-off-by: Jens Baumgart <jens.baumgart@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

No Eclipse support for this project is provided, because the
Jetty project does not publish a complete P2 repository.

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