C git 1.8.2 supports setting the equivalent of RequestPolicy.TIP with
uploadpack.allowtipsha1. 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.
Defer figuring out the effective RequestPolicy to later in the
process. This is a minor semantic change to fix a bug: previously,
calling setRequestPolicy(ADVERTISED) _after_ calling
setBiDirectionalPipe(true) would have reintroduced the race condition
otherwise fixed by 01888db892.
Change-Id: I264e028a76574434cecb34904d9f5944b290df78
This protocol capability, new in C git 1.8.2, corresponds to
RequestPolicy.TIP, so advertise it if that request policy was set.
Change-Id: I0d52af8a7747e951a87f060a5124f822ce1b2b26
Users of UploadPack may set a custom RefFilter or AdvertisedRefsHook
that limits which refs are advertised, but clients may learn of a
SHA-1 that the server should have as a ref tip through some
alternative means. Support serving such objects from the server side
with a new RequestPolicy.
As with ADVERTISED, we need a special relaxed RequestPolicy to allow
commits reachable from the set of valid tips for unidirectional
connections.
Change-Id: I0d0cc4f8ee04d265e5be8221b9384afb1b374315
Previously it took 1200ms to create a reverse index (sorted by offset).
Using a simple bucket sort algorithm, that time is reduced to 450ms.
The bucket index into the offset array is kept, in order to decrease
the binary search window.
Don't keep a copy of the offsets. Instead, use nth position
to lookup the offset in the PackIndex.
Change-Id: If51ab76752622e04a4430d9a14db95ad02f5329d
Without update, index is wrongly detected to be dirty
when picking the second commit.
Change-Id: Idf47ecb33e8bd38340d760806d629f67be92d2d5
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Bug: 411963
Currently, the offset can only be retrieved by ObjectId or iterating all
of the entries. Add a method to lookup the offset by position in the
index sorted by SHA1.
Change-Id: I45e9ac8b752d1dab47b202753a1dcca7122b958e
The original code was able to process only one WWW-Authenticate
header in an HTTP response, and if this header was not one of
two expected, authentication failed regardless of that there
could be other headers in the response.
All WWW-Authenticate headers in an HTTP response have to be
browsed to find one of supported, i.e. Basic or Digest.
By that if both are present, the Digest one should be used
as more preferable.
Bug: 357719
Change-Id: Icf601a41fec63f7d40308f3c85aaa4f71a7c095b
Signed-off-by: Alex Rukhlin <arukhlin@microsoft.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
All bugs reported for gc have been fixed and it seems we reached a
stable implementation.
Change-Id: I78a96ee2103beb48325da0f6ee10b2498bdc0267
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
These scripts were created to bootstrap the initial contribution for
Eclipse using information from the pre-Eclipse history. We are well
past the point where the project will rewrite history in order to
correct copyright statements, so these tools no longer make sense
to keep in the tip of the tree.
Change-Id: If68419ead0766035d17a21a53a3e5e761eaa70c4
/tmp is a symbolic link and some tests break when the path
gets canonicalized by JGit or Jetty. Allow Jetty to serve
symlinks by setting init parameter "aliases" to true [1].
[1] http://wiki.eclipse.org/Jetty/Howto/How_to_serve_symbolically_linked_files
Change-Id: I45359a40435e8a33def6e0bb6784b4d8637793ac
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
In 36144e12d8 tests were changed to use the system tmp directory as defined
by java.io.tmpdir, which was then overridden in the pom files to usea custom
directory that made som tests work, but not all.
Change-Id: I2fa04878f8830ad9c9b32a6f3fe8d2e2d66fe411
See change I08bed4275af9ec52aa4d7054067ac82f6a3c9781, where fixing such
warning lead to complaints.
If fixing is not wanted, disable it instead.
Change-Id: If31d4028fa1c6377a11e83ed5688b45701cec68b
* stable-3.0:
Prepare post 3.0.0.201306101825-r builds
JGit v3.0.0.201306101825-r
Make JGit test work with both hamcrest 1.1 (juno) and 1.3 (kepler)
Fix version.sh to not overwrite ${project.version}
Prepare post 3.0.0 RC3 builds
JGit v3.0.0.201306040240-rc3
Change-Id: I5b1db1f5b69bad1136dd21b956e798f63b1ba0ee
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The hamcrest library has moved things around. This problem applies only
to the test, not plugin runtime.
Change-Id: I5b97f356d8595dbdc9e91d157558e40561a6a30d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If the --format option is not given and the output filename is,
then infer the format from that filename. Otherwise match
"git archive" by defaulting to tar (this is a change from the
existing "jgit archive" default behavior, which was to default to
zip).
Change-Id: I5806bc48a403d05e4cfc3c180b82b33ad7cfae7f
Introduce a setFilename() method for ArchiveCommand so callers can
specify the intended filename of the produced archive. If the
filename ends with .tar, the format will default to tar; if .zip, zip;
if .tar.gz, gzip-compressed tar; and so on.
This doesn't affect "jgit archive" because it doesn't support the
--output=<file> option yet. A later patch might do that.
Change-Id: Ic0236a70f7aa7f2271c3ef11083b21ee986b4df5
Attempts to write entries with too-long filenames currently error out:
$ jgit.pgm/target/jgit archive HEAD >test.tar
java.lang.RuntimeException: file name 'org.eclipse.jgit.http.server/src/org/eclipse/jgit/http/server/resolver/DefaultReceivePackFactory.java' is too long ( > 100 bytes)
at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:288)
at org.eclipse.jgit.archive.TarFormat.putEntry(TarFormat.java:92)
at org.eclipse.jgit.archive.TarFormat.putEntry(TarFormat.java:62)
at org.eclipse.jgit.api.ArchiveCommand.writeArchive(ArchiveCommand.java:293)
at org.eclipse.jgit.api.ArchiveCommand.call(ArchiveCommand.java:322)
at org.eclipse.jgit.pgm.Archive.run(Archive.java:97)
at org.eclipse.jgit.pgm.TextBuiltin.execute(TextBuiltin.java:174)
at org.eclipse.jgit.pgm.Main.execute(Main.java:213)
at org.eclipse.jgit.pgm.Main.run(Main.java:121)
at org.eclipse.jgit.pgm.Main.main(Main.java:95)
That's because the default longFileMode is LONGFILE_ERROR, which
throws an exception for filenames longer than 100 characters. Switch
to LONGFILE_POSIX. While at it, handle large files and filenames with
strange encodings, too.
This requires commons compress 1.4, which introduced support for large
files and POSIX long filenames.
Change-Id: I04d5427eec0968b129f55d7a4c6021039a494828
Also the pgm feature should depend on the jgit feature to ensure that
all needed bundles are available.
Change-Id: I670e8262cdace4323d3883717efe4b5e5e06f4c7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Avoid that the packaging build picks an older jgit version coming with
eclipse platform by using a target platform which allows to define the
dependencies more precisely.
Change-Id: I39bba3baa4517e2b5e5fe0de096e756f2904e3e9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
OSGi 4.01 comes with package org.osgi.framework version 1.3 [1] which
has the BundleActivator interface needed by org.eclipse.jgit.archive.
OSGi 5.0 matches package org.osgi.framework version 1.7 [2].
[1] http://www.osgi.org/javadoc/r4v401/
[2] http://www.osgi.org/javadoc/r5/core/
Change-Id: I10f78e5eb02b5d03395f23d2f0ad039caf565269
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Document archive formats, the archive format interface, and the
parameters of the GitAPIException constructors. Noticed by eclipse.
Reported-by: Dani Megert <Daniel_Megert@ch.ibm.com>
Change-Id: I22b5f9d4c0358bbe867c1906feec7c279e214273
This makes the functionality of registering all formats from the
org.eclipse.jgit.archive package available in contexts where
FormatActivator cannot be built because the OSGi core framework is not
readily available to build against.
Change-Id: If8e3487e933783a7e12f8e1838cbfe0b5862ce80
* stable-3.0:
Prepare post 3.0.0-rc2 builds
JGit v3.0.0.201305281830-rc2
Support refspecs with wildcard in middle (not only at end)
Fix multiple bugs in RawSubStringPattern used by MessageRevFilter
Handle short branch/tag name for setBranch in CloneCommand
Add missing Bundle-Localization header
Apply tree filter marks when pairing DiffEntry for renames
Improve feature names to become understandable by end users
Update kepler orbit version to R20130517111416
Fix BatchRefUpdate progress-monitoring so it doesn't count twice
Fix AnyObjectId's generic type declaration of Comparable
Fix DiffFormatter NPEs for DiffEntry without content change
Fix CommitCommand not to destroy repo
Fix the parameters to an exception
Prepare post 3.0.0 M7 builds
JGit v3.0.0.201305080800-m7
Change-Id: Ia8441c9796f01497e0d90e672c0aaf60520a0098
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Add a static start() method to FormatActivator to allow outside
classes such as the Archive subcommand of the jgit program to use it
without a BundleContext. This way, the list of formats only has to be
maintained in one place.
While at it, build a list of registered formats at start() time, so
stop() doesn't have to repeat the same list of formats.
Suggested-by: Shawn Pearce <spearce@spearce.org>
Change-Id: I55cb3095043568740880cc9e4f7cde05f49c363c
The following refspec, which can be used to fetch GitHub pull requests,
is supported by C Git but was not yet by JGit:
+refs/pull/*/head:refs/remotes/origin/pr/*
The reason is that the wildcard in the source is in the middle.
This change also includes more validation (e.g. "refs//heads" is not
valid) and test cases.
Bug: 405099
Change-Id: I9bcef7785a0762ed0a98ca95a0bdf8879d5702aa