* stable-3.3:
Update scripts to deploy jgit on Maven central
Prepare 3.3.1-SNAPSHOT builds
JGit v3.3.0.201403021825-r
Fix merge/cherry-picking in CRLF mode
Expose the received pack size in ReceivePack
Revert "Add getPackFile to ReceivePack to make PostReceiveHook more usable"
Avoid an NPE after 7b01a53692
Add a launcher for Java 7 tests
Remove obsolete getRepositoryMethod from WorkingTreeIterator
Fix NPE when WorkingTreeIterator does not have a repository set
Add getPackFile to ReceivePack to make PostReceiveHook more usable
Possibility to limit the max pack size on receive-pack
Package httpclient and httpcore in o.e.j.http.apache.feature
Change-Id: I814a150980854bbaabd767f97b062d247af6cb50
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Java spec requires the @Deprecated annotation on any deprecated
field or method. Add the missing annotation to fields and methods
already declared deprecated in the javadoc.
Change-Id: Ic0ef24b43cfd99ac947e771ef5a28e493c304274
This fixes a case where we have CRLF in the repo but
LF in the worktree and are in autocrlf mode.
Change-Id: I0388270c1cf0fd22dfd513bcaa404eb97268d39d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
PostReceiveHooks can make use of this information to, for example,
update a cached size of the Git repository.
Change-Id: I2bf1200959a50531e2155a7609c96035ba45b10d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
usable"
This reverts commit 2670fd427c.
By returning an instance of File from the ReceivePack.getPackFile the
abstraction of the persistence implementation was broken.
Change-Id: I28e3ebf3a659a7cbc94be51bba9e1ad338f2b786
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
While fixing an NPE, I introduced another one in a deprecated isModified
method. It cannot avoid NPE's entirely, which is the reason the method
is deprecated
Change-Id: I5147c1c94621586dd84bd11e6090a954523b6c1c
Just like we have launcher for other packages
Change-Id: I140b88b8fdcab08d6515cd1f0ba9a53a9701f60d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The method was added for symlink support, but isn't needed anymore.
Since it was added for this release it's like it never existed.
Change-Id: I422cd1dcdfa40b25ba3d6e08b112159dae9a4353
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
It's strange that we have that member since it is not so clear
when it it set or not.
Change-Id: I53903a264f46866d249901a3cd9f9295028aa6bd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
doCheckout() is called only if --no-checkout option is not set.
Bug: 428917
Change-Id: I350bef446dd7a37613b9506aae99679569bd36e1
Signed-off-by: Kaloyan Raev <kaloyan.r@zend.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
During a checkout we want to prevent to overwrite unsaved local file
content. Jgit was therefore checking whether the file to overwrite is
dirty or missing and would raise a conflict if this was the case. That
was wrong. It should only check if the file is dirty. It's ok to
"overwrite" a missing/non-existing file.
Change-Id: I63c3a94f663c87f09170fdf8b1b1bf4ed5246fc5
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Some of our Windows users have reported sporadic file system access
problems related to ObjectDirectory(Inserter) file deletion code in
combination with antiviral/firewall tools. For one of these users the
problem was fairly reproducible and changing deletion to RETRY solved
his problem.
Change-Id: I1e4001d5557fca693b7bac401268599467cb0c9e
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
Having access to the pack file that was created by the ReceivePack
may be useful for post receive hooks. For example, a hook may want
to check the size of the received pack and the created index.
Change-Id: I4d51758e4565d32c9f8892242947eb72644b847d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The maxPackSizeLimit, when set, will reject a pack if it exceeds
that limit.
This feature is intended to provide a mechanism to control disk space
quota on Git repositories.
Change-Id: I83d8db670875c395f8171461b402083323e623a5
CQ: 7896
When adding the new feature o.e.j.http.apache.feature in
I4adfecd56d84ee24a50cadb1700c8be56e4172a3 in order to make the
httpclient based implementation optional I missed to also move the
apache libraries.
Change-Id: I7285458a70aee3dd6faf739b68a0b5783b8da01d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-3.3:
Move Apache httpclient based HTTP support to a separate bundle
Prepare post 3.3.0RC1 builds
JGit v3.3.0.201402191814-rc1
[findBugs] Don't ignore exceptional return value of File.mkdir()
[findBugs] Don't rely on default encoding
[findBugs] Don't call toString() on a string
Change-Id: I50f91e1d3c1d29a44502f4bb9f0e6c05e21342b7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This move avoids that all consumers of org.eclipse.jgit depend on Apache
httpclient. Also add another feature to make this optional for OSGi
consumers as well.
Change-Id: I5ef5e00c53678b9e1d7cfd54bbca3ff6f1c1c967
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When git-core renames or copies a file and the mode differs the
header shows the mode change first, then the rename or copy data:
diff --git a/COPYING b/LICENSE
old mode 100644
new mode 100755
similarity index 92%
rename from COPYING
rename to LICENSE
index d645695..54863be
--- a/COPYING
+++ b/LICENSE
@@ -56,20 +56,6 @@
JGit relies on this ordering inside of FileHeader. Parsing "new file
mode NNN" after "copy from/to" or "rename from/to" resets the change
type to be ADD, losing the COPIED or RENAMED status and old path.
This fixes a 4 year old bug in Gerrit Code Review that prevents
opening a file for review if the file was copied from another file,
modified in this change, and the mode was updated (e.g. execute
bit was added).
Change-Id: If4c9ecd61ef0ca8e3e1ea857301f7b5c948efb96
[ms: added test case]
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This change implements the http connection abstraction with the help of
org.apache.http.client.HttpClient. The default implementation used by
JGit is still the JDK HttpURLConnection. But now JGit users have the
possibility to switch completely to org.apache.httpclient. The reason
for this is that in certain (e.g. cloud) environments you are forced to
use the org.apache classes.
Change-Id: I0b357f23243ed13a014c79ba179fa327dfe318b2
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Previously all HTTP communication was done with the help of
java.net.HttpUrlConnection. In order to make JGit usable in environments
where the direct usage of such connections is not allowed but where the
environment provides other means to get network connections an
abstraction for connections is introduced. The idea is that new
implementations of this interface will be introduced which will not use
java.net.HttpUrlConnection but use e.g.
org.apache.client.http.HttpClient to provide network connections.
One example: certain cloud infrastructures don't allow that components
in the cloud communicate directly with HttpUrlConnection. Instead they
provide services where a component can ask for a connection (given a
symbolic name for the destination) and where the infrastructure returns
a preconfigured org.apache.http.client.HttpClient. In order to allow
JGit to be running in such environments we need the abstraction
introduced in this commit.
Change-Id: I3b06629f90a118bd284e55bb3f6465fe7d10463d
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This method always returns false and is private so it cannot be
overridden at runtime by a subclass. Drop the method and the branch
that can never be taken.
Change-Id: I4d3edbf469c6739dca191e62ea580bdb534b67a4
These methods do not touch instance members and can avoid the
implicit "this" argument.
Change-Id: I01c30bb22266eed1c9db18bdf9f90c1c1590e3ec
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Also imply remoteBranchName to match current branch name if it wasn't
configured in branch configuration.
Bug: 424812
Change-Id: Id852cedaefb2a537b6aa3c330b9861efad052f11
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
For example with following URL,
amazon-s3://.jgit@mybucket/foo.git
if ~/.jgit is missing, jgit command will throw a NullPointerException.
With this patch, a reasonable error message will be emitted:
fatal: Cannot read file /Users/jamesyonan/.jgit
Change-Id: I1d366f2d55e170d2972715c657c8e2d10c8d87d2
Signed-off-by: James Yonan <james@openvpn.net>
Read options that control squashing, whether or not to commit the merge
and regarding fast forwarding from the configuration and use them if no
explicit values for these options have been provided to MergeCommand.
Change-Id: Ifdaed4b5e4adc142657c03c8e78b709a99eeddbd
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When the caller specifies to JGit in advance that a ref-update is a
non-fast-forward update, and that those are permitted, we should never
need to call the potentially expensive isMergedInto() check. Re-checking
that the older commit is /not/ reachable from the newer is superfluous.
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I4bbf593de4dcea6b6f082881c1a33cb3a6a7fb89
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
Formerly the 4-arg constructor did not do this, which was unfortunate
as that constructor's the only way for an external user of JGit to set
the /type/ of the ref-update - which you might want to do to indicate
that the update is expected to be a UPDATE_NONFASTFORWARD, and thus does
not require expensive isMergedInto() calculations:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I84c5e4927131e105bed93e31a62da6367c78de32
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
When no explicit value is set via FetchCommand.setRemoveDeletedRefs()
checks if pruning is enabled in the configuration.
The following commit introduced the prune config to C Git:
737c5a9cde
Change-Id: Ida79d335218e1c9f5c6e2ce03386ac8a1c0b212e
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
According to Win32 API, you need to specificy whether a symlink
points to a file or directory. These tests suggests a symlink created
for a file, can actually point to a directory. We can also create the
link before the target exists, so at least in this respect Windows
symbolic links appears to work as POSIX links.
On POSIX systems these tests have no relevance.
Change-Id: Id3991a4fc4333087c6f569acf04f503b0a0f170d
Matthias Sohn
Robin Rosenberg
Shawn Pearce
Saša Živkov
Christian Halstrick
Kaloyan Raev
Marc Strapetz
James Yonan
Konrad Kügler
Roberto Tyley