Remove the S20181031145145 Orbit definition; that one was for our
purposes broken (mistakes in the org.apache.sshd-core and
net.i2p.crypto.eddsa receipes).
Change-Id: I8246d0837bc80165dd23780236b58fd9fe2fe0bc
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Also replace native git_repository rule with Starlark rule. This is
needed because in recent Bazel versions native git_repository rule
is deprecated.
Change-Id: I2c19fd31693a930d7d35fdbb93bfa4abf21fa2aa
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
The removed method and the new interface method only affect implementors
which is ok in a minor release following OSGi semantic versioning.
Change-Id: Ia5e55bd803965c7590c9278eecc6bdd36241383f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The copyfile entry in the manifest file copies the contents of the file
but doesn't keep the executable flag. This is inconsistent with repo
tool behaviour, plus is natural to expect that the copy of a executable
file is executable.
Transfer the executable bit when copying the file, aligning the
RepoCommand with repo tool and user expectations.
Change-Id: I01b24f482d5939e01d496f032388b3a5c02a912a
Signed-off-by: Ivan Frade <ifrade@google.com>
The RepoCommand.RemoteReader interface doesn't offer access to the mode
of a file. Caller can only default to mark the copied objects as regular
files, losing e.g. the executable bit (if set).
Add a new method readFileWithMode that returns the contents and mode of
the remote file. It supersedes the readFile method, that is marked as
deprecated.
Now callers can set correctly the file mode of the copied file.
Change-Id: I8fce01e4bc5707434c0cbc4aebbae1b6b64756f0
Signed-off-by: Ivan Frade <ifrade@google.com>
Many tests verify the contents of files in a try-with-resources
incantation that clutters the code.
Extract that verification to an "assertContents" method, that is easier
to read.
Change-Id: If430eac6f5b9ae352e42b2d43867ceb6cd618fbb
Signed-off-by: Ivan Frade <ifrade@google.com>
237abe6a added method getDeepenNots() with a default implementation and
method getDeepenNotFlag() to the interface DepthWalk. This affects
implementers which is ok in minor release following OSGi semantic
versioning.
Change-Id: I1c872da261fc6825e1e310127761b8b8a6d397d4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The only reference to this externalized text was deleted in c88d34b0.
Change-Id: Iecc7cc89192d69431dddb6550a02f66f0b09accc
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Patterns should treat \r in file names as normal characters
Change-Id: Ica3e0fa4a58acf5326db46bb28571fe5f20f6cd2
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
This allows clients to use the --shallow-exclude parameter (producing a
"deepen-not <ref>" line when communicating with the server) in their fetch
commands when fetching against a JGit server using protocol v2.
Note that the implementation in this commit is somewhat inefficient, as
described in the TODO comment in DepthGenerator.
Change-Id: I9fad3ed9276b624d8f668356ffd99a067dc67ef7
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
In C Git, when a client fetches with "git fetch --shallow-since=<date>
origin <ref>", and all commits reachable from <ref> are older than
<date>, the server dies with a message "no commits selected for shallow
requests". That is, (1) the --shallow-since filter applies to the commit
pointed to by the ref itself, and (2) there is a check that at least one
commit is not filtered out. (The pack-protocol.txt documentation does
not describe this, but the C implementation does this.)
The implementation in commit 1bb430dc21 ("UploadPack: support
deepen-since in protocol v2", 2018-09-27) does neither (1) nor (2), so
do both of these.
Change-Id: I9946327a71627626ecce34ca2d017d2add8867fc
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
The request receives a list of capabilities and takes out the "agent" to
offer it on its own setter (getAgent).
Do this at parse time: when reading the line if the capability is
"agent" set it directly in the builder.
This makes the treatment of "agent" consistent in v0/v1 and v2.
Change-Id: Ie4f9f2cad8639adeeaef4921df49a30a8ce5b42f
Signed-off-by: Ivan Frade <ifrade@google.com>
All of the input lines passed to pre-push hook scripts must be properly
terminated by '\n', so that normal shell scripts like the git-supplied
pre-push.sample work properly, even when pushing just a single branch.
With the old code, hook scripts that use the following pattern didn't
process the last line, because 'read' has a non-zero exit status when
EOF is encountered:
while read local_ref local_sha remote_ref remote_sha; do ... done
Change-Id: Id899662ed3fedef6c314fc4b2ddf91a6dcb98cbb
Signed-off-by: Markus Keller <markus.kell.r@gmail.com>
Use Integer.valueOf() to avoid the warning by implicit conversion due to
usage as argument object in String.format().
Change-Id: Ib314f629d54ae1ce9729c3837d66ce8982a1898a
Signed-off-by: Michael Keppler <Michael.Keppler@gmx.de>
Before this commit, a force checkout would fail if there
were any conflicting files. After this commit, a force
checkout will overwrite the conflicting files, as expected.
Making this work required fixing a bug in DirCacheCheckout.
Before this commit, when DirCacheCheckout had
failOnConflict=false, it would delete all conflicting files
from the working copy and just leave them missing. After
this commit, DirCacheCheckout overwrites conflicting files
with the merge tree.
This change in DirCacheCheckout causes "reset --hard" and
"revert --abort" to behave as expected (previously they
would simply delete conflicting files, now they will be
overwritten from the merge tree).
Change-Id: If7e328ee792ef6511ab7d9c26d8d77c39210ec9f
Signed-off-by: Ned Twigg <ned.twigg@diffplug.com>
* stable-5.0:
All commits from stable-5.0 are already in stable-5.1 due to an
accidental merge of stable-4.11 into stable-5.1 by I3ec3c9af4.
Change-Id: I8a89d103be2b2cb7657e82a124e7db41239a2447
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
UploadPack.getPeerUserAgent() doesn't produce the expected results for
protocol v2 requests. In v2, the agent reported in the request (in an
"agent=" line) is not in the clientCapabilities but in a field on its
own. This makes getPeerUserAgent default to the transport user agent.
Making "agent" a shared property between protocol v0/v1 and v2 fixes the
problem, simplifies the function and harmonizes the implementation
between protocol versions.
In a follow up commit the "agent" will be identified on parsing time,
instead of taking it from the client capabilities.
Change-Id: Idf9825ec4e0b81a1458c8e3701f3e28aafd8a32a
Signed-off-by: Ivan Frade <ifrade@google.com>
In protocol v2, a command request can be followed by server options
(lines like "agent=<>" and "server-option=<>"), but current code
doesn't accept those lines.
Advertise the "server-option" capability, parse the lines and add
them to the request objects.
Other code in JGit can see this options and act accordingly via the
protocol v2 hooks.
This should not require any change in the client side.
Change-Id: If3946390f9cc02d29644b6ca52534b6f757bda9f
Signed-off-by: Ivan Frade <ifrade@google.com>
Thomas Wolf
David Ostrovsky
Matthias Sohn
David Pursehouse
Ivan Frade
Michael Keppler
Marc Strapetz
Dave Borowitz
Jonathan Tan
Jonathan Nieder
Markus Keller
Ned Twigg