Passing int as an argument to String.format causes a warning:
The expression of type int is boxed into Integer
Most of these are already suppressed, but there are a couple that are
not. Add suppressions for those.
For the existing ones, move the suppression scope from the method to
the actual usage. Where necessary extract the usage out to a local
variable.
Change-Id: I7a7ff6dec49467e4b5c58d27a231c74e6e1c5437
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
The reftable format supports fast inverse (SHA1 => ref) queries.
If the ref database does not support fast inverse queries, it may be
advantageous to build a complete SHA1 to ref map in advance for
multiple uses. To let applications decide, this function indicates
whether the inverse map is available.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: Idaf7e01075906972ec21332cade285289619c2b3
Same as UploadPack, add a custom error handler.
Change-Id: I9c708aa5a22e01214c1d997fa6f72f4b8bf814f0
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Same as UploadPack. These methods do not handle exceptions and the
caller can handle them. This makes it possible to customize the error
handling.
Change-Id: Ia5203f80133cb5b3e5d754859b4167ac920eaf14
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Currently, there's no way for a user to customize the error handler for
the exception happened during unpacking an incoming pack file. Create an
error handler class and let them specify one.
Change-Id: Id07638ee58c88e1365181c3ddd17ee0266f3934d
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Instead of dropping a second exception, use try-with-resources so that
exception thrown by a hook is attached as a suppressed exception.
This removes a need of holding an exception that is thrown while
unpacking an incoming packfile.
Change-Id: I74d8b944931abbf53d9d1ae5db2e889639fba027
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
BaseReceivePack#sendStatusReport anyway needs to know
CAPABILITY_REPORT_STATUS. By moving this flag to BaseReceivePack,
simplify the status reporting code.
Change-Id: Iaa0878b1fc13057b687a7f01d25c85fd78c0423e
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
This gives a chance to handle an exception for a user. For example, when
an IOException is thrown while executing
`walk.parseAny(cmd.getNewId())`, it's always handled as
REJECTED_MISSING_OBJECT. However, IOException can mean a Git storage IO
error. By introducing an error handler class, a user can add a custom
error handler for these cases.
Change-Id: I3e03a536e1d8e137cb0f6e596d71642e72adde9e
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Move exception handling code to the caller side. This is a preparation
for adding a custom error handler that is similar to UploadPack.
Note that `catch (Throwable t)` will not affect the exception spec since
Java will do an analysis of rethrown exceptions. See
https://docs.oracle.com/javase/8/docs/technotes/guides/language/catch-multiple.html.
Change-Id: I973a63d4b079c2cd1402afb3f2956e18b7d5a00c
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
This removes a raw IOException at one level. Later we'll add a custom
exception handling mechanism like UploadPack.
Change-Id: I52a7423798c97b032d848351be8b6f144776b017
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
As UploadPackErrorHandler's Javadoc says, UploadPackServlet should have
called uploadWithExceptionPropagation and let UploadPackErrorHandler to
handle the exception. Fix UploadPackServlet.
Change-Id: I1f9686495fcf3ef28598ccdff3e6f76a16c8bca3
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Unlike ReceivePack, the V0/V1 UploadPack response does not support
sideband except for the packfile parts. By sending an error in a
sideband packet, the JGit client says "Expected ACK/NACK, got: ...".
Use an error packet always. The recent Git clients will understand it
better than out-of-context sideband packets.
Change-Id: Ied6787973d3b6860c0b95c7910d4e4312bb7a184
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
This partially reverts Ic6bb5e66. It made private some methods in
ReceivePack that were protected before. At least two of those methods
(#init and #receivePackAndCheckConnectivity) are used by out-of-tree
subclasses for tracing and testing.
Make ReceivePack#init() and ReceivePack#receivePackAndCheckConnectivity
protected again to allow tracing and testing.
Change-Id: I7ff22c091fbfc2d94009c449d58e7c5ac9f4f759
Signed-off-by: Ivan Frade <ifrade@google.com>
Canonical git shows the zero-Id for lines without commit, and
uses the current time stamp for such lines.
Also consider lines without commit when calculating the field
widths.
Change-Id: If0bee9b3e7f90861ad0f387f68e52ecc4a53dfd7
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
When a conflicting file was blamed, JGit would not identify lines
coming from the merge parents. The main cause for this was that
Blame and BlameCommand simply added the first DirCacheEntry found
for a file to its queue of candidates (blobs or commits) to consider.
In case of a conflict this typically is the merge base commit, and
comparing a auto-merged contents against that base would yield
incorrect results.
Such cases have to be handled specially. The candidate to be
considered by the blame must use the working tree contents, but
at the same time behave like a merge commit/candidate with HEAD
and the MERGE_HEADs as parents. Canonical git does something very
similar, see [1].
Implement that and add tests.
I first did this for the JGit pgm Blame command. When I then tried
to do the same in BlameCommand, I noticed that the latter also
included some fancy but incomplete CR-LF handling. In order to
be able to use the new BlameGenerator.prepareHead() also in
BlameCommand this CR-LF handling was also moved into BlameGenerator
and corrected in doing so.
(Just considering the git config settings was not good enough,
CR-LF behavior can also be influenced by .gitattributes, and even
by whether the file in the index has CR-LF. To correctly determine
CR-LF handling for check-in one needs to do a TreeWalk with at
least a FileTreeIterator and a DirCacheIterator.)
[1] https://github.com/git/git/blob/v2.22.0/blame.c#L174
Bug: 434330
Change-Id: I9d763dd6ba478b0b6ebf9456049d6301f478ef7c
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* stable-5.5:
Bazel: Use java_plugin and java_binary from @rules_java in jmh.bzl
Bazel: Add missing newlines at end of BUILD files
Change-Id: Ie32c3bae056fb0745892e6c20ad37d4994542d96
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* stable-5.4:
Bazel: Use java_plugin and java_binary from @rules_java in jmh.bzl
Bazel: Add missing newlines at end of BUILD files
Change-Id: I3dd2554cbad5bb224c2799b6b133fe91ab10abc3
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* stable-5.3:
Bazel: Use java_plugin and java_binary from @rules_java in jmh.bzl
Bazel: Add missing newlines at end of BUILD files
Change-Id: I21878c42fd9abf7d858b534300df0fffe4bad431
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* stable-5.2:
Bazel: Use java_plugin and java_binary from @rules_java in jmh.bzl
Bazel: Add missing newlines at end of BUILD files
Change-Id: Ie5e66f2e26c057c81101b0d110f91ea479eb362d
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* stable-5.1:
Bazel: Use java_plugin and java_binary from @rules_java in jmh.bzl
Bazel: Add missing newlines at end of BUILD files
Change-Id: Ic1dc84a6c4a1cf430d329627642583fd6e0d0eaa
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
When this class was split from DfsReftableDatabase in commit
2b1e942729 (reftable: split off generic
code from DFS code, 2019-09-26), we forgot to carry over the license
header.
Change-Id: I8698001dfb69f58784df643ef0185ab2d55e52aa
Reported-by: Masaya Suzuki <masayasuzuki@google.com>
Signed-off-by: Jonathan Nieder <jrn@google.com>
Forgot to add this in commit 989a927a5f
(checkNotAdvertisedWants: Be lazy convering Ref to RevCommit,
2019-11-20).
Change-Id: I5c1177ac60eabb3a71959bbad4537e076a901b7e
Signed-off-by: Jonathan Nieder <jrn@google.com>
Reftable-enabled repositories don't have a file called HEAD. Check for
reftable/ instead.
This fixes repository creation on reftable in Gerrit.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I778c2be01d96aaf135affae4b457b5fe5b483bee
Following OSGi semantic versioning which tolerates breaking implementers
in a minor release.
Change-Id: I4600c5ee9cd4ae209b69870a5d1367f83678617e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The checker is creating a new bitmap per branch leading to excessive
memory consumption. For the reachability check one bitmap with the
reachability of all branches aggregated is enough.
Build the reachability bitmap with a filter. The filter itself uses it
to emit only commits not reached before and the caller to check what
targets have been reached already.
BitmapCalculator is not required anymore.
Change-Id: Ic5c62f77fe0f188913215b7eaa51d849a9aae6a5
Signed-off-by: Ivan Frade <ifrade@google.com>
The ref points to an ObjectId that then is translated into a RevCommit.
This translation can be costly and with the incremental reachability
check is probably not needed for most of the elements.
Delay the translation from ObjectId to RevCommit to when it is needed.
Use Streams, that have the laziness built-in, all the way from Ref to
RevCommit.
This should reduce the latency for reachability checks over big sets of
references.
Change-Id: I28693087321b2beff3eaa1f3d2e7840ab0eedc6d
Signed-off-by: Ivan Frade <ifrade@google.com>
Preparatory change. Converting ObjectIds to RevCommits is potentially
expensive and in the incremental reachability check, it is probably not
required for all elements in the collection.
Pass a Stream to the reachability checker. In the follow up we make
the conversion from ObjectId to RevCommit in the stream (i.e. on
demand). This should reduce the latency of reachability checks over big
sets of references.
Change-Id: I9f310e331de5b0bf8de34143bd7dcd34316d2fba
Signed-off-by: Ivan Frade <ifrade@google.com>
UploadPack needs to check if object ids that weren't advertised before
are reachable from the references visible to the user. In the
bitmap-based reachability check, this is done incrementally: checking
against one reference, if anything remaining adding a second and so on.
It is more efficient to check first more common references (e.g. refs/heads/*)
Sort the references for the reachability checker. This should solve the
connectivity earlier and require less bitmap creation and less memory.
Change-Id: I48ac10d71e29fab2d346479802401eaea4aacb5c
Signed-off-by: Ivan Frade <ifrade@google.com>
David Pursehouse
Matthias Sohn
Han-Wen Nienhuys
Terry Parker
Masaya Suzuki
Jonathan Nieder
Ivan Frade
Thomas Wolf