- ObjectWalk.getTreeDepth() returns int hence there is no need to use
long depths in the lowestDepthVisited map.
- Also fix boxing warnings introduced in 0a15cb3a.
Change-Id: I6d73b6f41d5d20975d02f376c8588e411eaff0ec
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Replace:
in the "core section"
in the "diff section"
in the "merge section"
with:
in the "core" section
in the "diff" section
in the "merge" section
Change-Id: Ided7bf73e9c8aae4fc4e43d5d5b9f6d7e3066f0a
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Making gitlinks and folders match in a tree walk was the wrong
approach to fix bug 467631. The problem is that in such a conflict
the tree walk may then not descend into the folder.
Revert the changes to Paths.java and PathsTest.java from commit
4678f4b. Instead test for the problem case from bug 467631 explicitly
in IndexDiff. Add Daniel's test case from bug 545162, and add yet
another test case for DiffEntry.scan() that covers the problem
originally reported in bug 545162.
Bug: 545162
Change-Id: Ie2214c5d5ee32ac6596b621f0f1c7b86d38fa9b7
Also-by: Daniel Veihelmann <daniel.veihelmann@gmail.com>
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
If a tree is visited during pack and filtered out with tree:<depth>, we
may need to include it if it is visited again at a lower depth.
Until now we revisit it no matter what the depth is. Now, avoid
visiting it if it has been visited at a lower or equal depth.
Change-Id: I68cc1d08f1999a8336684a05fe16e7ae51898866
Signed-off-by: Matthew DeVore <matvore@gmail.com>
If we are traversing a tree which is too deep, then there is no need to
traverse the children. Skipping children is much faster than traversing
the possibly thousands of objects which are directly or indirectly
referenced by the tree.
Change-Id: I6d68cc1d35da48e3288b9cc80356a281ab36863d
Signed-off-by: Matthew DeVore <matvore@gmail.com>
This is used when fetching, and in particular to populate a partial
clone or a virtual file system cache as the user navigates. With this,
a client can pre-fetch a few directories deeper than only the current
directory.
depth:0 will omit all trees, and is useful if you only want to fetch
the commits of a repository, or fetch just a single tree or blob object.
depth:1 will fetch only the root tree of all commits fetched. depth:2
will fetch the root tree and all blobs and tree objects directly
referenced from it. depth:3 gets one more level, and so on. depth:#
will not filter a blob or tree that is explicitly marked wanted.
Bitmaps are disabled when this filter is used.
This implementation is quite slow because it iterates over all omitted
objects rather than skipping them. This will be addressed in follow-up
commits.
Change-Id: Ic312fee22d60e32cfcad59da56980e90ae2cae6a
Signed-off-by: Matthew DeVore <matvore@gmail.com>
This reverts commit 39b0b51b12. Before
that change, SubmoduleWalk.forPath transferred ownership to the caller
on success. Afterward, it returns a closed SubmoduleWalk to the caller,
which does not appear to be intentional.
Change-Id: I9381daac5153706e24fd9117700089848b58c54e
Replace simple uses of Iterator with a corresponding for-loop.
Also add missing braces on loops as necessary.
Change-Id: I708d82acdf194787e3353699c07244c5ac3de189
Signed-off-by: Carsten Hammer <carsten.hammer@t-online.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
DepthGenerator marks commits reinteresting for the ones that are
reachable from unshallow commits as it walks over the revisions. Those
unshallow commits won't necessarily be processed first. Because of this,
even if a commit is reachable from unshallow commits, if it's processed
before the uninteresting commits, it will not be processed as
reinteresting and processed as uninteresting. This causes unshallow
git-fetch to be failed.
This changes DepthGenerator to process unshallow commits first
independent to their depth. This makes uninteresting flag carry work
properly.
Change-Id: I94378271cf85fbe6302cefc19a167d8cf68e1a69
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Keep track of the original cause for a packfile invalidation.
It is needed for the sysadmin to understand if there is a real
underlying filesystem problem and repository corruption or if it is
simply a consequence of a concurrency of Git operations (e.g. repack
or GC).
Change-Id: I06ddda9ec847844ec31616ab6d17f153a5a34e33
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Since Java 7 the diamond operator can be used instead of explicit
type parameters.
Change-Id: I2dee5fce7afebb1d9088eeaec4484ee58b4fa492
Signed-off-by: Carsten Hammer <carsten.hammer@t-online.de>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Use of String.equals("") can be replaced with with String.length() == 0
(for JDK5 and lower) or String.isEmpty() (for JDK6 and higher)
Change-Id: Id1462d22c5d249485d87993263a9239809e73c55
Signed-off-by: Carsten Hammer <carsten.hammer@t-online.de>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Do not reload packfiles when their associated filesnapshot is not
modified on disk compared to the one currently stored in memory.
Fix the regression introduced by fef78212 which, in conjunction with
core.trustfolderstats = false, caused any lookup of objects inside
the packlist to loop forever when the object was not found in the pack
list.
Bug: 546190
Change-Id: I38d752ebe47cefc3299740aeba319a2641f19391
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Add resolveTipSha1, an inverse of exactRef(String ...), to RefDatabase
and provide a default implementation that runs in O(n) time where n is
the number of refs. For RefTable, provide an implementation that runs
in O(log(n)) time.
[ifrade@google.com: with tests in InMemoryRepositoryTest to exercise
the reftable code path, too]
Change-Id: I2811ccd0339cdc1c74b42cce2ea003f07a2ce9e1
Signed-off-by: Patrick Hiesel <hiesel@google.com>
Signed-off-by: Ivan Frade <ifrade@google.com>
Use Files.delete() instead of File.delete(), and if there is
an exception thrown propagate it unless errors are to be ignored so
that the actual deletion failure cause is available to the caller
(and will be logged).
Change-Id: I5fdb5a4052942437ab365289ad4bb1b563c29456
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Add missing source bundles for
- org.eclipse.jgit.ant
- org.eclipse.jgit.archive
- org.eclipse.jgit.http.apache
- org.eclipse.jgit.http.server
- org.eclipse.jgit.junit
- org.eclipse.jgit.junit.http
- org.eclipse.jgit.junit.ssh
- org.eclipse.jgit.lfs
- org.eclipse.jgit.lfs.server
- org.eclipse.jgit.ui
Combine all source bundles into a single source feature
org.eclipse.jgit.source and delete the other source features.
Ensure all bundles are added to the jgit p2 repository.
Change-Id: I56785f49c940b79f41f763c26e63a4a820ed7cce
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The new references created in the peeling do not receive the update
index. In other words, the update index of a reference (if set) is lost
in the peeling.
Pass-through the update index to the newly created references.
Tested via InMemoryRepository, which uses DfsReftableDatabase.
Change-Id: I7ff7c737a9c3366fdec296a4d9b2e51d10227957
Signed-off-by: Ivan Frade <ifrade@google.com>
Code that creates references and wants to support ref dbs with and
without update indexes needs to set this value. This leds to a
proliferation of "-1" in the code base.
Make the "undefined" value a constant in the ref interface.
Change-Id: I2622a37536a84b4a4036dd55792e185486fa0628
Signed-off-by: Ivan Frade <ifrade@google.com>
- UploadPack.getFilterBlobLimit() didn't have a wrong @since tag but was
marked final shortly after 5.3 was released. This was probably caused by
using an outdated API baseline. Currently we should use 5.3.0 as the
baseline.
- remove unused filter on FS.fileAttributes()
Change-Id: I9adc1703e99a9ddb3ea2a1c12a83dccbc1f69a99
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Use .api_filters to suppress API baseline errors. The justification is
included in comments in that file.
Change-Id: I7b5c69d8d13733719b28ef7317fc9780ed2828d8
Signed-off-by: Matthew DeVore <matvore@gmail.com>
Inline newTreeVisit into enterTree and call the new method pushTree. Use
pushTree both for pushing children of the existing currVisit.
Change-Id: I75ea37f48b2befb738a3e88bed40ac08f1df9a03
Signed-off-by: Matthew DeVore <matvore@gmail.com>
Use the FilterSpec object so that less code has to know about the make-up of
FilterSpecs. When fields are added to FilterSpec, these pieces of code won't
need updating again.
Change-Id: I2b9e59a9926ff112faf62a3fa2d33c961a1779e5
Signed-off-by: Matthew DeVore <matvore@gmail.com>
This increases type-safety and is ground work for support of the
"tree:<depth>" filter.
Change-Id: Id19eacdcdaddb9132064c642f6d554b1060efe9f
Signed-off-by: Matthew DeVore <matvore@gmail.com>
When using @NonNull annotations in new code, if I write
public void setFrobber(@NonNull frobber) {
this.frobber = frobber;
}
then consumers of the JGit library that do not have nullness checking
enabled can easily pass in null by mistake. On the other hand, if I
write
public void setFrobber(@NonNull frobber) {
if (frobber == null) {
throw new NullPointerException();
}
this.frobber = frobber;
}
then Eclipse JDT complains:
Null comparison always yields false: The variable frobber is specified as @NonNull
Add a checkNotNull helper that offers the best of both worlds:
public void setFrobber(@NonNull frobber) {
this.frobber = checkNotNull(frobber);
}
Briefer code, null check is intact, and no warning.
Inspired by Guava's com.google.common.base.Preconditions.checkNotNull.
Change-Id: If59588d13a1119e899657ed2296931ea18ed0e2a
Matthias Sohn
David Pursehouse
Thomas Wolf
Matthew DeVore
Jonathan Nieder
Carsten Hammer
Masaya Suzuki
Luca Milanesio
Patrick Hiesel
Gunnar Wagenknecht
Ivan Frade
Han-Wen Nienhuys