Parsing an LFS pointer must check the input more to not run into
exceptions. LfsPoint.parseLfsPointer() is used in various places to
determine whether a blob is a LFS pointer; it is not only called with
valid LFS pointers. Tighten the validations and return null if they
fail. All callers already do check for a null return value.
Also, LfsPointer implemented Comparable but did not override equals().
This is rather unusual and actually warned against in the javadoc of
Comparable. Implement equals() and hashCode().
Add more tests.
Bug: 570744
Change-Id: I90ca264d0a250275cf1907e9dcfcee5eab80df0f
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Correct the minimum required version of Apache httpclient
org.eclipse.jgit.http.apache uses several features that exist only
since httpclient 4.4, but its MANIFEST.MF still had a lower bound of
4.3.0. Bump this to 4.4.0 for all packages from httpclient. 4.3.0 for
the packages from httpcore is fine.
Do a similar clean-up in the other bundles using packages from Apache
httpclient (http.test, lfs, lfs.server, lfs.server.test)
Bug: 570451
Change-Id: Iffdde2a9bd0d65db2e5201a08cffbf03597e2866
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
[spotbugs] parse time using thread-safe DateTimeFormatter
LfsConnectionFactory used a static SimpleDateFormat which isn't
thread-safe. Use DateTimeFormatter instead to fix this.
Change-Id: Id580251c999e1e412c269f37b29860d310124c89
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
LfsConnectionFactory#getLfsUrl: Fix unconditional break in for-loop
When iterating over the remote URLs to find one that matches "origin",
it always exits after the first iteration whether it has found the
remote or not. The break should be inside the conditional block so
that it exits when "origin" is found, otherwise continues to iterate
over the remaining remote URLs.
Found by Sonar Lint.
Change-Id: Ic969e54071d1cf095334007c1c1bab6579044dd2
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Running recent error prone version complaining on that code:
LfsPointer.java:171: error: [BadComparable] Possible sign flip from
narrowing conversion
return (int) (getSize() - o.getSize());
^
(see https://errorprone.info/bugpattern/BadComparable)
Did you mean 'return Long.compare(getSize(), o.getSize());'?
Bug: 562756
Change-Id: I0522f1025319a9290c448a064fbafdb4b16d1d59
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
When downloading LFS objects also accept response code 203 as successful
download. This response may be seen when downloading via a proxy.
Bug: 563022
Change-Id: Iee85fdb451b33369d08859872e5bfc2a67dffa6d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Reorder modifiers to follow Java Language Specification
The Java Language Specification recommends listing modifiers in
the following order:
1. Annotations
2. public
3. protected
4. private
5. abstract
6. static
7. final
8. transient
9. volatile
10. synchronized
11. native
12. strictfp
Not following this convention has no technical impact, but will reduce
the code's readability because most developers are used to the standard
order.
This was detected using SonarLint.
Change-Id: I9cddecb4f4234dae1021b677e915be23d349a380
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Matthias Sohn
Thomas Wolf
David Pursehouse
David Ostrovsky