David Pletcher [Sat, 1 Nov 2014 21:34:18 +0000 (14:34 -0700)]
Extract path info from requests without decoding
Gitiles malfunctions in conjunction with jgit and guice
because of a recent Guice bug fix. Work around the problem
by parsing the URI directly, bypassing the unescaping
performed by the getPathInfo method.
This rest of this message is copied from
https://gerrit-review.googlesource.com/#/c/60820/ :
The fix for Guice issue #745[1] causes getPathInfo() within the
GuiceFilter to return decoded values, eliminating the difference
between "foo/bar" and "foo%2Fbar". This is in spec with the servlet
standard, whose javadoc for getPathInfo[2] states that the return
value be "decoded by the web container".
Work around this by extracting the path part directly from the request
URI, which is unmodified by the container. This is copying the Guice
behavior prior to the bugfix.
Shawn Pearce [Tue, 25 Nov 2014 05:43:59 +0000 (21:43 -0800)]
Move checkPath from DirCacheCheckout to ObjectChecker
The bulk of the "is this sane" logic is inside of ObjectChecker. The
only caller for the version in DirCacheCheckout is an obtuse usage for
the static isValidRefName() method in Repository.
Deprecate the weird single use method in DirCacheCheckout and move all
code for checking a sequence of path components into ObjectChecker,
where it makes sense alongside the existing code that checks a single
component at a time.
Reuse a single ObjectChecker for the local platform, to avoid looking
up the system properties on each path string considered.
Michael Keppler [Fri, 28 Nov 2014 20:21:59 +0000 (21:21 +0100)]
Use baseline instead of centerline in PlotRenderer
If the text extent height of a to be rendered plot line is odd, then the
SWTPlotRenderer cannot calculate the correct Y position for drawing the
label and draws the label with a 1 pixel offset. SWT text drawing uses
the baseline as Y coordinate. Due to the given centerline API in the
AbstractPlotRenderer the overall calculation of the baseline for SWT is
effectively (height / 2) * 2, thereby rounding all odd heights downward
to the next even number.
This change pushes the division by 2 from the caller into the
implementations of drawText. A corresponding change will be pushed in
the egit repository.
Bug: 450813
Change-Id: I66f4e71873bb8e6f936fde573bbe4c35fe23a022 Signed-off-by: Michael Keppler <michael.keppler@gmx.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Andrey Loskutov [Wed, 22 Oct 2014 07:31:42 +0000 (09:31 +0200)]
Consider parent rules if ignore rule is negated
The change tries to make jgit behave more like native CLI git regarding
the negation rules. According to [1] "... prefix "!" which negates the
pattern; any matching file excluded by a previous pattern will become
included again." Negating the pattern should not automatically make the
file *not ignored* - other pattern rules have to be considered too.
The fix adds test cases for both bugs 448094 and 407475.
Shawn Pearce [Wed, 26 Nov 2014 00:14:33 +0000 (16:14 -0800)]
ResolveMerger: Use checkoutEntry during abort
The cleanUp path is trying to restore files that previously were
clean, but were overwritten in the work tree by a partial merge
attempt that has failed and needs to be aborted. Reuse the checkout
logic to write the file content and refresh the stat data.
Shawn Pearce [Tue, 25 Nov 2014 23:10:41 +0000 (15:10 -0800)]
Cleanup double stat update of symlinks in DirCacheCheckout
When writing a symlink the stat data should only be written once
into the DirCacheEntry, based on the symlink itself and not the
possibly resolved destination observed by java.io.File.
Refactor the code to handle symlinks and early return. This
removes the risk the blob stat info update is used against a
newly checked out symlink.
Hoist the file length stat update immediately after writing
the file, before a rename. This eliminates any race caused by another
process updating the file length after the rename and having it to
fall into the racily clean path.
Shawn Pearce [Tue, 25 Nov 2014 21:49:22 +0000 (13:49 -0800)]
Deprecate checkoutEntry variant that accepts File
Entries should only be written to the working tree managed by the
Repository. Simplify callers by passing only the entry and computing
the work tree location inside of the checkoutEntry method.
Shawn Pearce [Mon, 24 Nov 2014 19:38:09 +0000 (11:38 -0800)]
DirCacheCheckout: create only one ObjectReader
This deprecated method accidentally creates two ObjectReader
instances. Use the instance created one line above that is
correctly released in the finally block.
Shawn Pearce [Mon, 24 Nov 2014 22:51:09 +0000 (14:51 -0800)]
Allow configurable ObjectCheckers in fetch
RecievePack already honors fsck settings for safeForWindows and
safeForMacOS. Allow those same checks to be performed during fetch
through a caller-configurable ObjectChecker.
Default the fetch fsck options to match the current platform, as
it can be reasonably assumed the repository will be accessed here.
Shawn Pearce [Mon, 24 Nov 2014 19:38:09 +0000 (11:38 -0800)]
Deprecate checkoutEntry without ObjectReader
Callers should manage the ObjectReader, as this allows the JGit library to cache
context relevant information across files checked out at the same time. If the
caller only has one file to checkout, it should still explicitly manage the life
span of the ObjectReader.
Matthias Sohn [Thu, 13 Nov 2014 14:46:13 +0000 (15:46 +0100)]
Include the java7 feature in org.eclipse.jgit.feature
This way we no longer need to advertise it in the release train and can
uncategorize the jgit features without making it harder for users to
find and install the java7 feature.
Bug: 451276
Change-Id: I4c7dd0e1609fc1939d8ea83c01251dec59c228a3 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Andrey Loskutov [Fri, 7 Nov 2014 15:30:44 +0000 (16:30 +0100)]
Don't use java.util.regex for two simple wildcard cases
To improve ignore parser performance we can avoid using java.util.regex
code on simple wildcard patterns with leading or trailing asterisk. As
those patterns represent a majority of ignore rules, the index diff
performance can be drastically increased on huge repository with lot of
ignore rules.
BaseRepositoryBuilder.findGitDir() was not searching correctly for bare
repositories. E.g. when running org.eclipse.jgit.pgm.Log and the current
directory was that of a bare git repository an error "fatal: error:
can't find git directory" was raised. With this fix RepositoryBuilder
will also check whether the given directory is the root of a bare
repository.
Bug: 450193
Change-Id: I4d4ad42e24ca397745adb0f3385caee3bcf3a186 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit's ObjectDirectory implements the optimization that it remembers the
pack folders (.git/objects/pack) lastModified timestamp and doesn't
check for new packfiles in this folder if the lastModified attribute has
not changed.
In environments using NFS this can cause trouble. If multiple JGit
instances from multiple machines work on the same repository and one
instance creates a new ref and a new packfile (e.g. by doing a fetch)
then the other machines may detect the new ref but can't resolve the
referenced object because it doesn't detect that pack folder has a new
packfile. That's because NFS may cache file/folder metadata for quite a
long time and the pack folders modification time is not updated although
a new packfile is there and could be read.
The new config parameter core.trustfolderstat controls this behaviour.
The default is true and jgits behaviours is unchanged. But if this
parameter is set to false then jgit doesn't trust the pack directories
lastmodified anymore. Instead it will always iterate through the content
of that folder to detect new packfiles.
Change-Id: Ie3b4e92933286aa9916070a22422e629b3147f54 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Shawn Pearce [Mon, 10 Nov 2014 23:35:20 +0000 (15:35 -0800)]
Expand wildcard imports to specfic classes
JGit style is to import exactly the classes required, and never
to use "import foo.*" as the foo package could add new classes
in the future which are conflicting/confusing with the imports
already used by a source file.
Fix possible NPE in IndexDiff when not all submodules are cloned
The latest changes to IndexDiff just assumed that all configured
submodules are allways cloned. If a configured submodule did not exist
an exception was thrown. This is fixed by this commit.
Stefan Beller [Sat, 8 Nov 2014 02:51:18 +0000 (18:51 -0800)]
Implement atomic refs update, if possible by database
Inspired by the series[1], this implements the possibility to
have atomic ref transactions.
If the database supports atomic ref update capabilities, we'll
advertise these. If the client wishes to use this feature, either
all refs will be updated or none at all.
Make sure checkout doesn't report conflicts on ignored paths
In a situation where a certain path was ignored but a working tree file
with this path existed jgit didn't allow to checkout a branch which
didn't ignore this path but contained different content. JGit considered
this to be a checkout conflict to prevent overwriting the file in the
working tree and raised an error. This commit fixes this by ensuring
that ignored dirty working tree files don't lead to a checkout conflict.
Bug: 450169
Change-Id: I90288d314ffac73c24a9c70a5181f8243bd4679a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Axel Richard [Wed, 5 Nov 2014 08:30:47 +0000 (09:30 +0100)]
Add new method IndexDiff#getPathsWithIndexMode
Get the list of paths that have the given file mode.
This helps EGit to efficiently determine which modified files are
symlinks and should be shown with a symlink icon in the staging view.
Bug: 429302
Change-Id: Id15f0c6f265667f5b8b57cc2d9f97de568371919 Signed-off-by: Axel Richard <axel.richard@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
RebaseCommand should ignore submodule modifications
Before a rebase happens the RebaseCommand checks that the working tree
is clean. We don't want to start a rebase on a dirty working tree. If
the working tree is dirty a rebase should not be allowed. But
RebaseCommand should ignore modifications done to submodules. E.g. if a
submodules HEAD points to <x> but the root repository has in index that
the submodule should point to <y> then this should not prohibit a
rebase. Also native git allows a rebase in this case. Since jgit's
StatusCommand has learned to ignore submodule changes this is now used
by the RebaseCommand to determine the repository state correctly.
Support for Submodule configuration submodule.<name>.ignore
For each submodule native git allows to configure which modifications to
submodules should be ignored by the status command. It is possible to
ignore "none", "all", "dirty", "untracked" [1]. This configuration is
now supported by IndexDiff. The StatusCommand offers the possibility to
specify this mode.
Andrey Loskutov [Mon, 11 Aug 2014 07:28:52 +0000 (09:28 +0200)]
Reimplementation of ignore rule parser
The current IgnoreRule/FileNameMatcher implementation scales not well
with huge repositories - it is both slow and memory expensive while
parsing glob expressions (bug 440732). Addtitionally, the "double star"
pattern (/**/) is not understood by the old parser (bug 416348).
The proposed implementation is a complete clean room rewrite of the
gitignore parser, aiming to add missing double star pattern support and
improve the performance and memory consumption.
The glob expressions from .gitignore rules are converted to Java regular
expressions (java.util.regex.Pattern). java.util.regex.Pattern code can
evaluate expression from gitignore rules considerable faster (and with
less memory consumption) as the old FileNameMatcher implementation.
Shawn Pearce [Fri, 17 Oct 2014 21:17:23 +0000 (14:17 -0700)]
Add retainOnReset(RevFlag) to RevWalk to simplify reset usage
Applications sometimes use a RevFlag instead of a Set<RevObject>
to track boolean state bits about objects being processed. However
this requires careful use of the resetRetain() methods to avoid an
accidental clearing of the RevFlag bits, effectively clearing the
Set<RevObject> the application wanted to track.
Simplify that use case by offering retainOnReset, a collection of
flags that are never cleared by the RevWalk.
Matthias Sohn [Mon, 13 Oct 2014 08:25:14 +0000 (10:25 +0200)]
Update URL of JGit Maven release repository
This repository is required to allow clirr to compare the API of the
checked out version against the API of the latest release of jgit. The
old Maven repository on the download server was replaced by Nexus a long
time back.
Change-Id: I05125407fb72531c6831ec721064b0dad278bde5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn [Thu, 25 Sep 2014 09:18:53 +0000 (11:18 +0200)]
Enable maven site generation for jgit
Generating the site:
$ mvn site:site
Local staging of the site:
$ mvn site:stage
the site is staged under ./target/staging/
If you can connect to build.eclipse.org over ssh
(ask webmaster if you are a committer and need ssh access)
you can deploy a local build of the site:
$ mvn site:deploy
The site is deployed under
http://download.eclipse.org/jgit/site/${project.version}
To select the ssh key to use for deploying over ssh add the following
section to your Maven settings.xml:
<server>
<id>jgit.website</id>
<username>username</username>
<privateKey>${user.home}/.ssh/id_rsa</privateKey>
<filePermissions>664</filePermission>
<directoryPermissions>775</directoryPermissions>
<configuration></configuration>
</server>
To deploy the site from Hudson https://hudson.eclipse.org/egit/
enable the Maven profile "build-server".
Change-Id: I7e64c8560ca75196d2232f111ffad953c14f013f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
(cherry picked from commit 6d00f0a09c67421d4ac9960c568f9c18ceb4a6a4)
When marking commits as uninteresting don't care if the tree exists
When during an ObjectWalk commits are marked as uninteresting we should
be tolerant against the situation that the commit exists in the repo but
the referenced tree is not exisiting. Since commit c4797fe98655b3d52d0a90ba44fce6e053db3b8b we are throwing
MissingObjectException in such a case. This semantic differs from native
git behaviour and may cause push operations to fail while they would
work in native git. See:
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03585.html
When marking commits as uninteresting don't care if the tree exists
When during an ObjectWalk commits are marked as uninteresting we should
be tolerant against the situation that the commit exists in the repo but
the referenced tree is not exisiting. Since commit c4797fe98655b3d52d0a90ba44fce6e053db3b8b we are throwing
MissingObjectException in such a case. This semantic differs from native
git behaviour and may cause push operations to fail while they would
work in native git. See:
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03585.html
Matthias Sohn [Fri, 26 Sep 2014 13:45:46 +0000 (15:45 +0200)]
Merge branch 'stable-3.5'
* stable-3.5:
Prepare 3.5.1-SNAPSHOT builds
JGit v3.5.0.201409260305-r
Fix PackWriterBitmapWalker handling non-existing uninteresting objects
Enable maven site generation for jgit
Generate javadocs as part of Maven site project reports
Compare API changes with clirr against 3.4.1
[cli] Use chaining credentials provider to enable .netrc
Add chaining credentials provider
[Java 8] Configure doclint to accept missing descriptions
Do not use .netrc implicitly if no CredentialsProvider was set
Prepare post 3.5.0-rc1 builds
JGit 3.5.0.201409071800-rc1
Fix the ls-remote command when there is no local repo
Change-Id: Iaa4485cac6ff9c7917380e89e12e416e0f52a557 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When writing new packs it should be allowed to specify objects as "have"
(objects which should not be included in the pack) which do not exist in
the local repository.
This works with the traditional PackWriter, but when PackWriter was
working on a repository with bitmap indexes and used
PackWriterBitmapWalker then this feature was broken. Non-existing "have"
objects lead to MissingObjectExceptions. That broke push and Gerrit
replication. When the replication target had branches unknown to the
replication source then the source repository wanted to build pack files
where "have" included branch-tips which were unknown in the source
repository.
Bug: 427107
Change-Id: I6b6598a1ec49af68aa77ea6f1f06e827982ea4ac Also-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn [Thu, 25 Sep 2014 09:18:53 +0000 (11:18 +0200)]
Enable maven site generation for jgit
Generating the site:
$ mvn site:site
Local staging of the site:
$ mvn site:stage
the site is staged under ./target/staging/
If you can connect to build.eclipse.org over ssh
(ask webmaster if you are a committer and need ssh access)
you can deploy a local build of the site:
$ mvn site:deploy
The site is deployed under
http://download.eclipse.org/jgit/site/${project.version}
To select the ssh key to use for deploying over ssh add the following
section to your Maven settings.xml:
<server>
<id>jgit.website</id>
<username>username</username>
<privateKey>${user.home}/.ssh/id_rsa</privateKey>
<filePermissions>664</filePermission>
<directoryPermissions>775</directoryPermissions>
<configuration></configuration>
</server>
To deploy the site from Hudson https://hudson.eclipse.org/egit/
enable the Maven profile "build-server".
Change-Id: I7e64c8560ca75196d2232f111ffad953c14f013f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn [Wed, 17 Sep 2014 21:30:46 +0000 (23:30 +0200)]
Add chaining credentials provider
The chaining credentials provider sequentially tries to obtain
credentials from a list of credential providers and returns the
credentials from the first provider which can provide them.
Change-Id: I499f304119d7066d011dbde3556dee6facee8ab0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit should offer the possibility to do a garbage collection in
"aggressive" mode. In this mode garbage collection more aggressively
optimize the repository at the expense of taking much more time.
Technically a aggressive mode garbage collection differs from a
non-aggressive one by:
- not reusing packed objects found in old packs. Recompress every object
- the configuration pack.window is set to 250 (the default is 10)
- the configuration pack.depths is set to 250 (the default is 50)
The associated classes in org.eclipse.jgit.api and the command line
command in org.eclipse.jgit.pgm expose this new option.
The configuration parameters gc.aggressiveDepth and gc.aggressiveWindow
have been introduced to configure this feature.
Matthias Sohn [Wed, 17 Sep 2014 13:16:55 +0000 (15:16 +0200)]
Do not use .netrc implicitly if no CredentialsProvider was set
Do not silently set the NetRCCredentialsProvider if no
CredentialsProvider was set explicitly since applications may want to
have full control which provider should be used.
Bug: 444338
Change-Id: Ie096983bc1caa90443a504d302bfea8f2d26ab9e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
projects / jgit.git / log