| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Bug: 500059
Change-Id: I47f3f6749a67da52029f84e002d9b155ed56d2b7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
|
| |
|
|
|
| |
Change-Id: I50407e4a33e35b718ca40503fdd436f1f9f70fba
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the project-specific Eclipse settings to replace the use of the
org.eclipse.jdt.annotation.Nullable class the new JGit-specific
@Nullable annotation. I verified that Eclipse reports errors when the
return value of a method annotated with
@org.eclipse.jgit.annotations.Nullable is dereferenced without a null
check.
Also remove the Maven and MANIFEST.MF dependencies on
org.eclipse.jdt.annotation.
Eclipse null analysis uses three annotations: @Nullable, @NonNull and
@NonNullByDefault. All three are updated in this patch because it is
invalid to set the Eclipse preferences to empty values. So far only
@Nullable has been introduced in org.eclipse.jgit.annotations.
My personal preference is to follow the advice in Effective Java and
avoid the null-return idiom, and to avoid passing null values in
general. This sets the expectation is that arguments and return types
are assumed non-null unless otherwise documented. If that is the
expectation, then consistent application of @NonNull is redundant and
hurts readability by cluttering the code, obscuring the occasional
@Nullable annotation that really requires attention.
If the JGit community decides there is value in using the @NonNull and
@NonNullByDefault annotations we can add them--this change configures
Eclipse to use them.
Change-Id: I9af1b786d1b44b9b0d9c609480dc842df79bf698
Signed-off-by: Terry Parker <tparker@google.com>
|
| |
|
|
|
|
| |
Bug: 470647
Change-Id: I14d1983bb7c208faeffee0504e0567e38d8a89f3
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
|
| |
|
|
|
|
| |
Bug: 458475
Change-Id: Iea8f2236d4e6a94a8d14bb8cc685006ea3fd1bb7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
|
| |
|
|
| |
Change-Id: If534bd0aedaee6160679e965ad08ac30d5dac1c5
|
| |
|
|
|
|
|
|
| |
Making the methods static would gain little in performance,
make the code harder to change. Removing unncessary warnings
is more important.
Change-Id: If3e6aa9c1d92e58b4e7a8e246cf4aace237d7a7b
|
| |
|
|
|
|
|
|
| |
These settings were added by Eclipse simply by touching
the project settings. Adding these makes it simpler to see
what local changes have been made.
Change-Id: Iab0aa62530312eb0c78b03b5c6a632742bcc4978
|
| |
|
|
|
|
| |
Add compatibility filters to hide the breakage.
Change-Id: Icc1fdc29f15d734d488e49c9c37a18f5ac937903
|
| |
|
|
|
|
|
|
|
| |
See change I08bed4275af9ec52aa4d7054067ac82f6a3c9781, where fixing such
warning lead to complaints.
If fixing is not wanted, disable it instead.
Change-Id: If31d4028fa1c6377a11e83ed5688b45701cec68b
|
|
|
Allow use of ArchiveCommand without depending on the jgit command-line
tools.
To avoid complicating the process of installing and upgrading JGit,
this does not add a dependency by the org.eclipse.jgit bundle on
commons-compress. Instead, the caller is responsible for registering
any formats they want to use by calling ArchiveCommand.registerFormat.
This patch puts functionality that requires an archiver into a
separate org.eclipse.jgit.archive bundle for people who want it. One
can use it by calling ArchiveCommand.registerFormat directly to
register its formats or by relying on OSGi class loading to load
org.eclipse.jgit.archive.FormatActivator, which takes care of
registration automatically.
Once the appropriate formats are registered, you can make a tar or zip
from a git tree object as follows:
ArchiveCommand cmd = git.archive();
try {
cmd.setTree(tree).setFormat(fmt).setOutputStream(out).call();
} finally {
cmd.release();
}
Change-Id: I418e7e7d76422dc6f010d0b3b624d7bec3b20c6e
|
