On Android, the co-variant override of ConcurrentHashMap.keySet()
introduced in Java 8 was undone. [1] If compiled Java code calls that
co-variant override directly, one gets a NoSuchMethodError exception
at run-time on Android.

Making the code call that method via Map.keySet() side-steps this
problem.

This is similar to bug 496262, where the same problem cropped up when
compiling with Java 8 against a Java 7 target, but here we cannot use
bootclasspath. We build against Java 8, not against the Android version
of it.

Recent Android versions should have some bytecode "magic" that adds the
co-variant override in bytecode (see the commit referenced in [1]), but
on older Android version this problem may still occur. (Or perhaps the
"magic" is ineffective...) There are two pull requests on Github for
this problem, both from 2020, [2][3] while the Android commit [1] is
from March 2018. Apparently people still occasionally run into this
problem in the wild.

[1] 0e8b937ded/ojluni/src/main/java/java/util/concurrent/ConcurrentHashMap.java (1244)
[2] https://github.com/eclipse/jgit/pull/104
[3] https://github.com/eclipse/jgit/pull/100

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

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>

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

If the configuration parameter filter.<filterDriverName>.useJGitBuiltin
is set to true then for all corresponding filters JGit will try to
execute the built-in filter instead of the filter-command which is
defined in git configuration. It will fallback to the non-built-in
filters if no built-in filters are registered or if constructing them
leads to exceptions. If set to false JGit will not try to execute
built-in filters for the specified filter driver.

Example: The configuration contains the following lines

  [filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    useJGitBuiltin = true

Addtionally the .gitattributes file in the root of the working tree
contains:

    *.bin filter=lfs

In this case when new content is added similar to "git add 1.bin" then
the following will happen:

  - jgit will check whether a built-in command factory was registered
    for the command "jgit://builtin/lfs/clean". If that is true the
    factory is used to create a built-in filter command and that
    command is used to filter the content
  - Otherwise jgit will call the external program "git lfs clean ..."
    to do the filtering

Change-Id: Idadb1db06b1e89e7031d7ed6319904973c367d38

JGit supports clean filters defined in repository configuration. The
filters are implemented as external programs filtering content by
accepting the original content (as seen in the working tree) on stdin
and which emit the filtered content on stdout. To run such a filter JGit
has to start an external process and pump data into/from this process.

This commit adds support for clean filters which are implemented
in Java and which are executed by jgit's main thread. When a filter is
defined in the configuration as
"jgit://builtin/<filterDriverName>/clean" then JGit will lookup in a
static map whether a filter is registered under this name. If found
such a filter is called to do the filtering.

The functionality in this commit requires that a program using JGit
explicitly calls the JGit API to register built-in implementations for
specific clean filters. In follow-up commits configuration parameters
will be added which trigger such registrations. Other commits will add
implementations for lfs filters.

Change-Id: I0344d3c54801c9a46e5a606c5df17e5f2e17b2be