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.
Change-Id: Ib57fba6cb4b774ccff8c416ef4d32e2b390f16a9
cgit has this feature for some time. This will teach JGit to send symbolic refs,
too.
Change-Id: I7cb2ab4e6d31a838a0af92eac64535fdb66ed74a
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
This silences the Maven warning "'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing"
Change-Id: I036210fefb6bd81ca04fcd91aaba0f9d0c1e8862
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
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.
Bug: 450466
Change-Id: I80428441cc8d5de5468813f841d89322413eed8b
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
Actually the test only allows a range from [1,255], so let's name the
variable so.
Change-Id: Iecdb8149b83389c67e3cd2f64f4a654c175475be
Signed-off-by: Stefan Beller <sbeller@google.com>
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.
Change-Id: I5693408c777e5843ec65fff1163d5d717849fa34
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.
Bug: 450567
Change-Id: Iabe3b196d998c19483082e5720038ebddaeb1890
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.
[1] http://thread.gmane.org/gmane.comp.version-control.git/259019/focus=259024
Change-Id: I7b5d19c21f3b5557e41b9bcb5d359a65ff1a493d
Signed-off-by: Stefan Beller <sbeller@google.com>
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>
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>
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.
Bug: 446922
Change-Id: I487bf7484dca3f5501e6e514584e2871524eea19
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.
[1] http://git-scm.com/docs/gitmodules
Change-Id: Ifd81d574a680f9b4152945ba70f8ec4af4f452c9
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.
CQ: 8828
Bug: 416348
Bug: 440732
Change-Id: Ibefb930381f2f16eddb9947e592752f8ae2b76e1
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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.
Change-Id: I4c05b89b1398e4a4f371eac3a5d1d5edddec838f
* stable-3.5:
Prepare 3.5.2-SNAPSHOT builds
JGit v3.5.1.201410131835-r
Only hide gitdir if the repository isn't bare
Change-Id: I171e5fb8718cb6829bb1357859c95b4a29910ac6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResetCommand threw an NPE if neither mode nor path was defined. Instead
it should default to a mixed reset like native git does.
Change-Id: I455902394f9e7b0c7afae42381f34838f7f2a138
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
* origin/stable-3.5:
When marking commits as uninteresting don't care if the tree exists
Change-Id: I66559a72ed7284cb721cf929512af884c0db2d61
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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 6d00f0a09c)