Add methods that allow to unregister repositories from the
RepositoryCache individually.
Bug: 470234
Change-Id: Ib918a634d829c9898072ae7bdeb22b099a32b1c9
Signed-off-by: Tobias Oberlies <tobias.oberlies@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
For loose objects an expiration date can be set which will save too
young objects from being deleted. Add the same for packfiles. Packfiles
which are too young are not deleted.
Bug: 468024
Change-Id: I3956411d19b47aaadc215dab360d57fa6c24635e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This may be used by e.g. a custom reflog implementation to record
this information along with the ref update.
Change-Id: I44adbfad704b76f9c1beced6e1ce82eaf71410d2
These differ subtly from a PersonIdent, because they can contain
anything that is a valid User ID passed to gpg --local-user. Upstream
git push --signed will just take the configuration value from
user.signingkey and pass that verbatim in both --local-user and the
pusher field of the certificate. This does not necessarily contain an
email address, which means the parsing implementation ends up being
substantially different from RawParseUtils.parsePersonIdent.
Nonetheless, we try hard to match PersonIdent behavior in
questionable cases.
Change-Id: I37714ce7372ccf554b24ddbff56aa61f0b19cbae
The signature is intended to be passed to a verification library such
as Bouncy Castle, which expects these lines to be present in order to
parse the signature.
Change-Id: I22097bead2746da5fc53419f79761cafd5c31c3b
This is the subclass of IOException already thrown by
BaseReceivePack#recvCommands when encountering an invalid value on
the wire. That's what PushCertificateParser is doing too, so use the
same subclass.
Change-Id: I1d323909ffe70757ea56e511556080695b1a0c11
The default behavior is to read a repository's signed push
configuration from that repo's config file, but this is not very
flexible when it comes to managing groups of repositories (e.g. with
Gerrit). Allow callers to override the configuration using a POJO.
Change-Id: Ib8f33e75daa0b2fbd000a2c4558c01c014ab1ce5
Add a missing continues to prevent falling through to the command
parsing section. The first continue happens when the command list is
empty, so change the condition to see whether we have read the first
line, rather than any commands.
Fix comparison to BEGIN_SIGNATURE to use raw line with newline.
Change-Id: If3d92f5ceade8ba7605847a4b2bc55ff17d119ac
a85e817d is a slightly breaking API change to classes that were
technically public and technically released in 4.0. However, it is
highly unlikely that people were actually depending on public behavior,
since there were no public methods to create PushCertificates with
anything other than null field values, or a PushCertificateParser that
did anything other than infinite loop or throw exceptions when reading.
Change-Id: I1d0ba9ea0a347e8ff5a0f4af169d9bb18c5838d2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
UploadPackLogger is incorrectly named--it can be used to trigger any
post upload action, such as GC/compaction. This change introduces
PostUploadHook/PostUploadHookChain to replace
UploadPackLogger/UploadPackLoggerChain and deprecates the latter.
It also introduces PackStatistics as a replacement for
PackWriter.Statistics, since the latter is not public API.
It changes PackWriter to use PackStatistics and reimplements
PackWriter.Statistics to delegate to PackStatistics.
Change-Id: Ic51df1613e471f568ffee25ae67e118425b38986
Signed-off-by: Terry Parker <tparker@google.com>
This method is documented to take a branch name (not a possibly null
string). The only way a caller could have set null without either
re-setting to a sane value afterward or producing NullPointerException
was to also call setNoCheckout(true), in which case there would have
been no reason to set the branch in the first place.
Make setBranch(null) request the default behavior (remote's default
branch) instead, imitating C git's clone --no-branch.
Change-Id: I960e7046b8d5b5bc75c7f3688f3a075d3a951b00
Signed-off-by: Jonathan Nieder <jrn@google.com>
A non-bare clone command with null remote produces a
NullPointerException when trying to produce a refspec to fetch against.
In a bare repository, a null remote name is accepted by mistake,
producing a configuration with items like 'remote.url' instead of
'remote.<remote>.url'. This was never meant to work.
Instead, let's make setRemote(null) undo any previous setRemote calls
and re-set the remote name to DEFAULT_REMOTE, imitating C git clone's
--no-origin option.
While we're here, add some tests for setRemote working normally.
Change-Id: I76f502da5e677df501d3ef387e7f61f42a7ca238
Signed-off-by: Jonathan Nieder <jrn@google.com>
call() throws InvalidRemoteException if uri == null, so there should
never be reason to leave the URI set to null. Document this.
Change-Id: I7f2cdbe8042d99cf8a3c1a8c4c2dcb58c5b8c305
Signed-off-by: Jonathan Nieder <jrn@google.com>
These commands' monitor fields can never be null unless someone passes
null to setProgressMonitor. Anyone passing null probably meant to
disable the ProgressMonitor, so do that (by falling back to
NullProgressMonitor.INSTANCE) instead of saving a null and eventually
producing NullPointerException.
Change-Id: I63ad93ea8ad669fd333a5fd40880e7583ba24827
Signed-off-by: Jonathan Nieder <jrn@google.com>
A project's name attribute is required according to repo's
doc/manifest-format.txt:
<!ELEMENT project (annotation*,
project*)>
<!ATTLIST project name CDATA #REQUIRED>
Enforcing this in code makes reading easier (in particular making it
clearer that getName() and getPath() can never return null).
Change-Id: I8c7014dd6042183d7fecb2202af5acdc384aa8e4
Signed-off-by: Jonathan Nieder <jrn@google.com>
- Consistently return structured data, such as actual ReceiveCommands,
which is more useful for callers that are doing things other than
verifying the signature, e.g. recording the set of commands.
- Store the certificate version field, as this is required to be part
of the signed payload.
- Add a toText() method to recreate the actual payload for signature
verification. This requires keeping track of the un-chomped command
strings from the original protocol stream.
- Separate the parser from the certificate itself, so the actual
PushCertificate object can be immutable. Make a fair attempt at deep
immutability, but this is not possible with the current mutable
ReceiveCommand structure.
- Use more detailed error messages that don't involve NON-NLS strings.
- Document null return values more thoroughly. Instead of having the
undocumented behavior of throwing NPE from certain methods if they
are not first guarded by enabled(), eliminate enabled() and return
null from those methods.
- Add tests for parsing a push cert from a section of pkt-line stream
using a real live stream captured with Wireshark (which, it should
be noted, uncovered several simply incorrect statements in C git's
Documentation/technical/pack-protocol.txt).
This is a slightly breaking API change to classes that were
technically public and technically released in 4.0. However, it is
highly unlikely that people were actually depending on public
behavior, since there were no public methods to create
PushCertificates with anything other than null field values, or a
PushCertificateParser that did anything other than infinite loop or
throw exceptions when reading.
Change-Id: I5382193347a8eb1811032d9b32af9651871372d0
C git's receive-pack.c strips trailing newlines in command lists when
present[1], although send-pack.c does not send them, at least in the
case of command lists[2]. Change JGit to match this behavior.
Add tests.
This also fixes parsing of commands in the push cert, which, unlike
commands sent in the non-push case, always have trailing newlines.
[1] 7974889a05/builtin/receive-pack.c (L1380)
where packet_read_line chomps newlines:
7974889a05/pkt-line.c (L202)
[2] 7974889a05/send-pack.c (L470)
Change-Id: I4bca6342a7482a53c9a5815a94b3c181a479d04b
The new submodule layout where GITDIR of a submodule is located at
<parent-repo-GITDIR>/modules/<submodule-path> was only used during
clone. Teach SubmoduleAddCommand to use the new layout.
Bug: 469666
Change-Id: Ie97dc0607b71499560444616f362bccee9cce515
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* changes:
Allow setting detail message and cause when constructing most exceptions
Use message from ServiceNotAuthorizedException, ServiceNotEnabledException
dumb HTTP: Clarify AsIsFilter by introducing req and res locals
Clarify description of ServiceNotAuthorizedException
Move ObjectCountCallback and WriteAbortedException to package
org.eclipse.jgit.transport, so that they'll become public API.
Change-Id: I95e3cfaa49f3f7371e794d5c253cf6981f87cae0
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
This reverts commit 96eb3ee397, which
broke Gerrit tests that set a config value to 'null', serialize the
result, deserialize, and expect 'null' from Config.getString[1].
The intent of that commit was to make it possible to distinguish between
an absent and an empty config value, which we'll have to do with a new
method.
Revert the behavior change. Keep the tests from 428cb23f2de8, since
they test the behavior more precisely than the old tests did.
[1] https://gerrit-review.googlesource.com/68452
Change-Id: Ie8042f380ea0e34e3203e1991aa0feb2e6e44641
Signed-off-by: Jonathan Nieder <jrn@google.com>
Added callback in PackWriter and BundleWriter for the caller to get the
count of objects to write, and a chance to abort the write operation.
Change-Id: I1baeedcc6946b1093652de4a707fe597a577e526
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
C git 2.5 supports setting the equivalent of
RequestPolicy.REACHABLE_COMMIT with uploadpack.allowreachablesha1inwant.
Parse this into TransportConfig and use it from UploadPack. An explicitly
set RequestPolicy overrides the config, and the policy may still be
upgraded on a unidirectional connection to avoid races.
Change-Id: Id39771a6e42d8082099acde11249306828a053c0
Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
Change-Id: I351cee0ba2e77e3360846ac0c5368da3a322725c
Reported-by: Markus Keller <markus_keller@ch.ibm.com>
Signed-off-by: Jonathan Nieder <jrn@google.com>
exactRef(ref1, ref2, ref3) requests multiple specific refs in a single
lookup, which may be faster in some backends than looking them up one by
one.
firstExactRef generalizes getRef by finding the first existing ref from
the list of refs named. Its main purpose is for the default
implementation of getRef (finding the first existing ref in a search
path). Hopefully it can be useful for other operations that look for
refs in a search path (e.g., git log --notes=<name>), too.
Change-Id: I5c6fcf1d3920f6968b8b97f3d4c3a267258c4b86
Signed-off-by: Jonathan Nieder <jrn@google.com>
Unlike getRef(name), the new exactRef method does not walk the search
path. This should produce a less confusing result than getRef when the
exact ref name is known: it will not try to resolve refs/foo/bar to
refs/heads/refs/foo/bar even when refs/foo/bar does not exist.
It can be faster than both getRefs(ALL).get(name) and getRef(name)
because it only needs to examine a single ref.
A follow-up change will introduce a findRef synonym to getRef and
deprecate getRef to make the choice a caller is making more obvious
(exactRef or findRef, with the same semantics as getRefs(ALL).get and
getRefs(ALL).findRef).
Change-Id: If1bd09bcfc9919e7976a4d77f13184ea58dcda52
Signed-off-by: Jonathan Nieder <jrn@google.com>
I am developing an offline pack verification feature based on
PackParser. The birthday collision check is a prohibitive obstacle
to performance at scale because it interacts with the repository
to perform collision checks. This CL restores the checkObjectCollisions
flag that was removed in 9638e0aa87,
while changing the flag getter and setter to protected from public as a
precaution against misuse.
Change-Id: I363cd0c9de57c5e8659cdfe2d51b17823f4fe793
Signed-off-by: David Pletcher <dpletcher@google.com>
This is a perfectly valid construction according to C git:
$ echo -en '[a]\nx =' > foo.config
$ git config -f foo.config a.x; echo $?
0
Change-Id: Icfcf8304adb43c79e2b8b998f8d651b2a94f6acb
The C git API and command line tools distinguish between a key having
the empty string as a value and no key being present in the config
file:
$ echo -e '[a]\nx =' > foo.config
$ git config -f foo.config a.x; echo $?
0
$ git config -f foo.config a.y; echo $?
1
Make JGit make the same distinction. This is in line with the current
Javadoc of getString, which claims to return "a String value from the
config, null if not found". It is more reasonable to interpret "x ="
in the above example as "found" rather than "missing".
We need to maintain the special handling of a key name with no "="
resolving to a boolean true, but "=" with an empty string is still not
a valid boolean.
Change-Id: If0dbb7470c524259de0b167148db87f81be2d04a
Return -1 from PackWriter.Statistics.getBitmapIndexMises() when no
bitmap indices were found, to differentiate it from the case where
the bitmap indices contained all of the want/have commits.
Change-Id: I78d4600b462c19f62b347217a0b2c19eaaf3a14b
Signed-off-by: Terry Parker <tparker@google.com>
In particular, this means a RepositoryResolver, UploadPackFactory, or
ReceivePackFactory can set a detail message for
ServiceNotAuthorizedException or ServiceNotEnabledException with
information for the client about why access is not allowed.
Change-Id: I38e1798e1e9d09b5e75cefacd9d85f25729235a9
Signed-off-by: Jonathan Nieder <jrn@google.com>
This exception's detail message states
Service not permitted
and according to the Javadoc it indicates that the current user does not
have access to the service. In practice, though, callers handle this
exception by presenting a '401 Unauthorized' response to the client,
meaning that the user is unauthenticated and should authenticate.
Clarify the documentation and detail message to match the practice.
The exception message is not used anywhere except logs. No
client-visible effect intended.
Change-Id: I2c6be9cb74af932f0dcb121a381a64f2ad876766
Signed-off-by: Jonathan Nieder <jrn@google.com>
When CommitCommand.setOnly(path) is used a temporary index has to be
created containing only modifications for the specified pathes. The
process to fill this temporary index was broken because filling the
index was stopped when we reached the first untracked file. Instead the
process to fill the temporary index should continue until we processed
all pathes.
Bug: 451465
Change-Id: I22af50d70bd3b81e7c056358724956122b0d158d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
- throw an API exception instead of an internal exception to allow
applications to handle this problem
- improve error message to give hints about possible root causes
Bug: 464660
Change-Id: Ib7d18bb2eeeac0fc218daea375b290ea5034bda1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* changes:
Silence unused object warning in MyersDiff
Silence resource leak warnings where caller is responsible to close
Fix potential null pointer access in IndexDiffFilter
ObjectReader release method was replaced by close method but
WindowCursor was still implementing release method.
To prevent the same mistake again, make ObjectReader close method
abstract to force sub classes to implement it.
Change-Id: I50d0d1d19a26e306fd0dba77b246a95a44fd6584
Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
Early JGit code used comments to inform the Eclipse formatter about
where to break lines and used final in the hope of making code faster.
The ArchiveCommand command implementation imitated that style.
Nowadays the project relies less on the Eclipse formatter and relies
more on Java having sane performance with local variables that are not
explicitly marked 'final'. Removing the unnecessary empty comments and
'final' qualifiers makes this code more readable and more consistent
with recent JGit code.
Change-Id: I7a181432eda7e18bd32cf110d89c0efbe490c4f1
Signed-off-by: Jonathan Nieder <jrn@google.com>
Whether the output stream specified with setOutputStream() is closed by
ArchiveCommand.call() is murky and inconsistent:
- on success, it is closed
- if an exception is encountered when writing the archive, it is closed
- if an exception is encountered when calling createArchiveStream to
open the archive, we forget to close it
Close the output stream consistently to avoid leaks.
Now that the inner try-with-resources doesn't have its own finally
block, this allows us to merge the two try blocks.
It would be even better to never close the output stream. That will
involve more API changes to avoid silently breaking callers, so it is
deferred to a later change.
Change-Id: I0185bdaa60ecee4a541eab5d8ff6c9c4dbe40bf1
Signed-off-by: Jonathan Nieder <jrn@google.com>
When during a PushOperation the server hits an exception different from
UnpackException the JGit server behaved wrong. That kind of exceptions
are handled so late that the connection is already released and the
information whether to talk sideband to the client is lost. In detail:
ReceivePack.receive() will call release() and that will reset the
capabilities. But later on the stack in ReceivePackServlet.doPost() it
is tried to send a response to client now with reset capabilities (no
sideband!).
Change-Id: I0a609acc6152ab43b47a93d712deb65bb1105f75
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGits PushCommand and BasePackPushConnection were throwing generic
TransportExceptions when the pushed pack-file was rejected by the server
since it was too big. Let JGit better interprete the server's response
to detect this situation and throw a more specific exception.
This detection works by parsing the status line sent by the server. This
change only recognizes the response sent by a JGit based server. All
other servers which report such problems in a different way still lead
to a generic TransportExceptions.
Change-Id: Ic075764ea152939ce72c446252464620dd54edea
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The primary goal is to improve exception readability. Since this is a
standalone thread, just logging the stack trace of the caught
exception is not very useful:
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
at java.io.BufferedInputStream.read(BufferedInputStream.java:258)
at org.eclipse.jgit.util.FS$2.run(FS.java:451)
Providing a named class eliminates the "FS$2", and including the
command name provides a little more context in the error message.
A future improvement might include the stack trace that created the
GobblerThread as well.
Change-Id: Ibf16d15b47a85b6f41844a177e398c2fc94f27b0
RevWalks to find commits that are not in bitmap indices are expensive.
Track the count of commits that are enumerated via RevWalks as "bitmap
index misses" in the PackWriter.Statistics class.
Change-Id: Ie0135a0a0aeba2dfb6df78839d545006629f16cb
Signed-off-by: Terry Parker <tparker@google.com>
The SimilarityIndex class implements the useful capability of scoring
the similarity between two files. That capability is required for a
feature that's being developed in another package, to detect files
derived from a set of potential sources.
This CL adds a public factory method to create a SimilarityIndex from
an ObjectLoader. It grants public access to the SimilarityIndex class,
the score method, an inner exception class and a special marker
instance of that exception class.
Change-Id: I3f72670da643be3bb8e261c5af5e9664bcd0401b
Signed-off-by: David Pletcher <dpletcher@google.com>
If the thread reading a pack file is interrupted don't invalidate that
pack file.
This could happen when Gerrit invoked JGit for computing a diff in one
thread and waited for the call to finish from another thread, with a
timeout. When the timeout was reached the "diff" thread was interrupted.
If it happened to be in an IO operation, reading a pack file, an
InterruptedIOException was thrown and the pack file was marked as
invalid and removed from the pack list.
Invalidating the pack in that case could cause the project disappearing in
Gerrit as discussed in [1] and [2].
[1] https://groups.google.com/forum/#!topic/repo-discuss/CYYoHfDxCfA
[2] https://groups.google.com/forum/#!topic/repo-discuss/ZeGWPyyJlrM
Change-Id: I2eb1f98370936b5be541d96d70c3973cbfc39238
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Now that d7a4473 removed the gitprefix property, we did not have a way to
specify the path to the Git system config file in case
discoverGitSystemConfig() fails. Fix that by introducing a member variable
that caches the result of discoverGitSystemConfig() as well as a setter
method to overwrite the content of that variable.
Change-Id: Icd965bffbe2f11b18c9505ee2ddd2afad5b64d70
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Matthias Sohn