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>
Most relative-URL tests for SubmoduleInitCommand carry out the following
steps:
1. add a submodule at path "sub" to the index
2. set remote.origin.url in .git/config
3. configure .gitmodules, possibly using relative URLs, and see what
happens
resolveWorkingDirectoryRelativeUrl() is meant to test the fallback when
remote.origin.url is not set, to match C git which treats the URL as
relative to the cwd in that case. To do so, in step (2) it sets
remote.origin.url to null.
However, Config.setString when taking a null value does not actually
unset that value from the configuration --- it sets it to the empty
string. This means we are testing a behavior that C git never
supported. Use Config.unset instead.
Change-Id: I7af29fbbd333a2598843d62c320093c48b2ad972
Signed-off-by: Jonathan Nieder <jrn@google.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>
When sending an error response due to ServiceNotAuthorizedException or
ServiceNotEnabledException, usually we send a default message. In the
ServiceNotEnabledException case, we use
403 Git access forbidden
except in a dumb-HTTP-specific filter where we use the servlet
container's default 403 response:
403 Forbidden
In the ServiceNotAuthorizedException case, we use the servlet
container's default 401 response:
401 Unauthorized
There is one exception: a ServiceNotEnabledException when handling a
smart HTTP /info/refs request uses the message from the exception:
403 Service not enabled
Be more consistent by always using the message from the exception. This
way, authors of a RepositoryResolver, UploadPackFactory, or
ReceivePackFactory can provide a more detailed message when appropriate.
The defaults are
401 Unauthorized
403 Service not enabled
Change-Id: Id1fe1c2042fb96487c3671c1965c8a65c4b8e1b8
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>
* master:
Add more reports to maven site
Update project meta-data in pom.xml used for site generation
Update dependencies to the versions used in target platform
Update 4.5 target platform to use final Mars Orbit repository
Compare API changes in clirr report against 3.7.0
Fix CommitCommand.setOnly()
Add "src" folder to source folders of org.eclipse.jgit.test
Improve exception thrown when pull can't find advertised ref
Silence unchecked conversion warning in TransportSftp
Silence deprecation warning in WindowCacheConfig
Silence deprecation warning in DirCacheCheckout
Fix unchecked conversion warning in MergeFormatter
Fix hidden field warnings in bundle org.eclipse.jgit
Close WindowCursor using try-with-resources in UnpackedObject
Fix WindowCursor memory leak.
archive: Drop unnecessary empty comments and 'final' qualifiers on locals
Close 'out' consistently in ArchiveCommand.call
Fix that exceptions in ReceivePack cause Invalid Channel 101 exceptions
Better report too large pack-files from PushCommand
FS: Extract GobblerThread into a private static class
Add bitmap index misses to PackWriter.Statistics
Enable public access to SimilarityIndex scoring function
Add getters to RepoProject.
Silence unused object warning in MyersDiff
Silence resource leak warnings where caller is responsible to close
Silence false potential null pointer access warnings
Fix potential null pointer access in IndexDiffFilter
Add tests for ObjectFilter
Expose Sets helper to tests outside org.eclipse.jgit.api
Change-Id: I34b2bb45f51ed6f52a6bb1215de654ebb2ffde10
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Add the following additional reports:
- cross-reference report
- API changes report using clirr
- findbugs report
- surefire-report
Run
$ mvn test install site:site site:stage
to generate and stage the site
Also see
https://wiki.eclipse.org/EGit/Contributor_Guide#JGit_3
Change-Id: Ibb6a2e13e128d7728b3c632cc16bf79716dc75f5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Christian Halstrick
Jonathan Nieder
Shawn Pearce
Yuxuan 'fishy' Wang
Matthias Sohn
Fredrik Medley
David Pletcher
Dave Borowitz
Terry Parker