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>
* 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>
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
c4797fe986 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
Bug: 445744
Change-Id: Ib7dec10fd2ef1adbb8adbabb9d3d5a64e554286a
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
c4797fe986 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
Bug: 445744
Change-Id: Ib7dec10fd2ef1adbb8adbabb9d3d5a64e554286a
* 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>
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.
Bug: 444332
Change-Id: I024101f2810acf6be13ce144c9893d98f5c4ae76
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>
It can be useful for a server operator to know how long a pack
writer spent writing out objects, even if the request aborts and
never finishes.
Record more of the stats data inside of a finally block, to
ensure these can be included into the server's monitoring.
Change-Id: I00858aa393a948f8e742e64ae4c00953eadaef95
Some of these eliminations just reduces the number of warnings on
lines where messages are constructed that can/will be translated.
Change-Id: I6eddb39ccc8f2488741bb58540d9ec5f5665e2c4
Other .git files are not hidden with this patch
Change-Id: Idf63ca08d08f3a77c33f5848d02074f8d6a75758
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If the git server requires authentication and no CredentialsProvider is
registered TransportHttp.connect() would throw an NPE since it tries to
reset the credentials provider. Instead throw a TransportException
explaining the problem.
Change-Id: Ib274e7d9c43bba301089975423de6a05ca5169f6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Set the commit message to be used for the merge commit (in case one is
created)
Bug: 442886
Change-Id: Ie5ecc13822faa366f00b3daa07f74c8441cae195
Signed-off-by: Axel Richard <axel.richard@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If the packer fails, still obtain the stats and make them available
to the logger and the caller. Failures can frequently happen when
a client disconnects in the middle of a pack stream. Server admins
may still want to examine the timing metrics from counting and
compressing phases.
Change-Id: Iceae4f68b5473f4223d85c9edfb57837fc818eed
In such case, we use the name attribute as the default value of path.
Change-Id: I53fa312d6b64c6eb2240f08af7d1d60cea99192a
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
uninteresting
Using the ObjectWalk and marking a commit as uninteresting didn't mark
its root tree as uninteresting. This caused the "missing tree ..."
error in Gerrit under special circumstances. For example, if the
patch-set 2 changes only the commit message then the patch-set 1
and patch-set 2 share the same root-tree:
ps1 -> o o <- ps2
\ /
o root-tree
The transported pack will contain the ps2 commit but not the root-tree
object.
When using the BaseReceivePack.setCheckReferencedObjectsAreReachable
JGit will check the reachability of all referenced objects not provided
in the transported pack. Since the ps1 was advertised it will properly
be marked as uninteresting. However, the root-tree was reachable because
the ObjectWalk.markUninteresting missed to mark it as uninteresting.
JGit was then rejecting the pack with the "missing tree ..." exception.
Gerrit-issue: https://code.google.com/p/gerrit/issues/detail?id=1582
Change-Id: Iff2de8810f14ca304e6655fc8debeb8f3e20712b
Signed-off-by: Saša Živkov <sasa.zivkov@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
In Git 1.9 (5dbd767601 "support pushing from a shallow clone")
the git-core project intentionally broke the existing send-pack
protocol from shallow clients.
Shallow clients now transmit their shallow information during push,
ahead of the old-new command sequence. JGit must accept these lines
when presented.
To protect the server against clients sending partial history,
require the connectivity check when pushed to by a shallow client.
Change-Id: I46639366b0900052c376091e1688f07def44ab79
This matches what C Git does, see "stripped" in `man git-commit-tree`.
It also fixes the bug of the user where an user.email like "<>" would
show up as "<<>>" in EGit.
Bug: 439844
Change-Id: I567a3c620e191ce9d37d318417e63cb5d4483419
Signed-off-by: Robin Stocker <robin@nibor.org>
URIish.unescape() threw an ArrayIndexOutOfBoundsException if the given
url has incorrect percent-encoding (e.g. http://example.com/%gg). But an
URISyntaxException is much better to know the reason of the failure.
Change-Id: I3f40a26d43cd2eb4e32c11aba7dc2594bc1f98e2
Signed-off-by: Yi EungJun <eungjun.yi@navercorp.com>
This is necessary to ensure objects accessed by the TreeWalk come from
the associated ObjectInserter when the merger is a RecursiveMerger
instance and a virtual common base was constructed but not flushed.
Change-Id: Iebe739d30fd868ebc4f61dbfb714673146a2c3ec
According to http://stackoverflow.com/a/8381338, the maximum array
size is not Integer.MAX_VALUE, but Integer.MAX_VALUE - 8
Change-Id: I6ddc7470368acd20abf0885c53c89a982bb0f176
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
The native implementation of inflate() can set finished to return
true at the same time as it copies the last bytes into the buffer.
Check for finished on each iteration, terminating as soon as libz
knows the stream was completely inflated.
If not finished, it is likely input is required before the next
native call could do any useful work. Most invocations are passing
in a buffer large enough to store the entire result. A partial return
from inflate() will need more input before it can continue. Checking
right away that needsInput() is true saves a native call to determine
no bytes can be inflated without more input.
This should fix a rare infinite loop condition inside of inflation
when an object ends exactly at the end of a block boundary, and
the next block contains only the 20 byte trailing SHA-1.
When the stream is finished each new attempt to inflate() returns
n == 0, as no additional bytes were output. The needsInput() test
tries to add the length of the footer block to itself, but then loops
back around an reloads the same block as the block is smaller than
a full block size. A zero length input is set to the inflater,
which triggers needsInput() condition again.
Change-Id: I95d02bfeab4bf995a254d49166b4ae62d1f21346
This reverts commit b646578d89.
openInputStream() is never used in JGit, nor is it used by any
known working DFS implementation. The method was added as a
utility for reading back from a DfsInserter, but the final
implementation of that feature does not requrire this method.
Change-Id: I075ad95e40af49c92b554480f8993ef5658f7684
This allows callers performing multiple separate merges to reuse a
single ObjectInserter without flushing the inserter on each iteration
(which can be slow in the DFS case).
Change-Id: Icaff7d2bc2c20c873ce5a7d9af5002da84ae1c2b
This allows the RecursiveMerger to iteratively create new merge bases
without necessarily flushing packs to storage in the DFS case;
flushing only need happen at the end of the whole merge process.
Since Merger's walk now depends on its inserter, we need to construct
an inserter at Merger construction time. This should not be a
significant increase in overhead since unused inserters don't use any
resources (beyond a reference to the Repository).
We also must release and recreate the walk whenever setObjectInserter
is called, which can break usages where setObjectInserter is called in
the middle of stateful operations on the walk. No usages of this
method within JGit currently do this; the inserter is only ever set
before any stateful walk operations happen.
Change-Id: I9682a6aa4a2c37dccef8e163f132ddb791d79103
This kind of reverted 31148. URI.resolve actually can handle the absolute URL
well, the problem is only the missing "/".
Change-Id: Iee5866c005cbc1430dc20ee7db321b8b51afed30
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
In the DFS implementation, flushing an inserter writes a new pack to
the storage system and is potentially very slow, but was the only way
to ensure previously-inserted objects were available. For some tasks,
like performing a series of three-way merges, the total size of all
inserted objects may be small enough to avoid flushing the in-memory
buffered data.
DfsOutputStream already provides a read method to read back from the
not-yet-flushed data, so use this to provide an ObjectReader in the
DFS case.
In the file-backed case, objects are written out loosely on the fly,
so the implementation can just return the existing WindowCursor.
Change-Id: I454fdfb88f4d215e31b7da2b2a069853b197b3dd
Since 2badedcbe0 in-core merges can write up to 10 MiB
into a TemporaryBuffer.Heap strategy, where the data is stored
as a chain of byte[] blocks.
Support the inserter reading up to the streamFileThreshold (default 50
MiB) from the supplied input stream and hash the content to determine
if the merged result blob is already present in the repository. This
allows the inserter to avoid creating duplicate objects in more cases,
reducing repository pack file churn.
Change-Id: I38967e2a0cff14c0a856cdb46a2c8fedbeb21ed5
The base Merger class already has a single ObjectReader instance that
it handles releasing as necessary, so creating new readers is not
necessary.
Change-Id: I990ec43af7df448c7825fc1b10e62eadaa3e0c2a
Instead of always writing to disk use TemporaryBuffer.LocalFile to
store up to 10 MiB of merge result in RAM. Most source code will
fit into this limit, avoiding local disk IO for simple merges.
Larger files will automatically spool to a temporary file that
can be cleaned up in the finally, reducing the risk of leaving
them on disk and consuming space in /tmp.
Change-Id: Ieccbd9b354d4dd3d2bc1304857325ae7a9f34ec6
The only caller of writeMergedFile is updateIndex, and the only
user of this path object is the code within the method. This is
a no-op change that opens the door to refactoring the way temp
files are handled for inCore merges.
Change-Id: I863a303194689a806b667e55eb958e1decf046c1
When merging common ancestors to create a single virtual common
ancestor the commit does not need to be inserted into the Git
repository. Instead just mock it out in memory as part of the
merger's RevWalk pool.
Make the author and committer stable and predictable for any
given pair of merge bases. It is not necessary for the caller's
name or email to be used as the commit will not be written out.
Change-Id: I88d5ee4de121950e1b032a5c10486c9d2c42656c
Currently if the remote defined in repo manifest xml is non-relative (e.g.
"https://chromium.googlesource.com"), our code will break. This change fixed
that.
It also makes that remotes are ending with "/".
Change-Id: Icef46360b32227a9db1d9bb9e6d929c72aeaa8df
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Instead of passing on the start point as is to CreateBranchCommand, the
resolved ObjectId was used. Given this, CreateBranchCommand did not set
up tracking.
This also fixes CreateBranchCommand with setStartPoint(null) to use HEAD
(instead of NPEing), as documented in the Javadoc.
Bug: 441153
Change-Id: I5ed82b4a4b4a32a81a7fa2854636b921bcb3d471
Signed-off-by: Robin Stocker <robin@nibor.org>
Matthias Sohn