| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
In following changes we introduce a cache for the Blame CLI and it
should follow the XDG standard for the location.
Add support for XDG_CACHE_HOME following the XDG_CONFIG_HOME pattern.
Change-Id: I622f7eb7ff942fafdb5c5da877d1fb1507d5e482
|
| |
|
|
| |
Change-Id: I163957653b075f1f05a6219f4d23b340588ffcbd
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
* stable-7.1:
Do not load bitmap indexes during directory scans
Fix calculation of pack files and objects since bitmap
Pack: no longer set invalid in openFail()
Change-Id: I4516cd7f39418ddbb7db381f58aadc99b6d7e40d
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-7.0:
Do not load bitmap indexes during directory scans
Fix calculation of pack files and objects since bitmap
Pack: no longer set invalid in openFail()
Change-Id: I480a52909a7f3ee771947c0fd447433e10a9b19b
|
| | | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.10:
Do not load bitmap indexes during directory scans
Fix calculation of pack files and objects since bitmap
Pack: no longer set invalid in openFail()
Change-Id: I8846ad4745a360244f81518a028fed5f07086724
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, if a bitmap index had not been loaded yet, it would get
loaded during a directory scan. Loading a bitmap file can be expensive
and there is no immediate need to do so during a scan. Fix this by
simply setting bitmap index file names on the Packs during directory
scans so that bitmaps can be lazily loaded at some later point if they
are needed.
This change has the side affect of no longer marking a Pack valid if it
is currently invalid simply because a bitmap file has been found, as
there is no valid reason to do so and this can incorrectly mark a Pack
without an index, or with other issues valid. Since the initial lack of
a bitmap file, or an invalid one, or the deletion of one, would not
result in the Pack being marked invalid, there is no need to overturn
the invalid flag when a new bitmap file is found.
Change-Id: I056acc09e7ae6a0982acd81b552d524190ebb4be
Signed-off-by: Martin Fick <mfick@nvidia.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fromg git documentation[1]: While the pack-indexes provide fast lookup
per packfile, this performance degrades as the number of packfiles
increases, because abbreviations need to inspect every packfile and we
are more likely to have a miss on our most-recently-used packfile. For
some large repositories, repacking into a single packfile is not
feasible due to storage space or excessive repack times. (...)
The multi-pack-index (MIDX for short) stores a list of objects and
their offsets into multiple packfiles. (...) Thus, we can provide
O(log N) lookup time for any number of packfiles.
This is a writer of the multipack index format. The test only verifies
the "shape" of the file, when we get a parser we can check also the
values (specially the large offset handling).
On the JGit repository, the multipack index generated by this writer
passes the validation of `git multi-pack-index verify`.
[1] https://git-scm.com/docs/pack-format#_multi_pack_index_midx_files_have_the_following_format
Change-Id: I1fca599c4ebf28154f28f039c2c4cfe75b2dc79d
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
FileSnapshot relies on File attributes (which can be retrieved by the
stat() function on Unix) to quickly determine if a File was modified
without reading file content or listing content of a directory.
On NFS this doesn't work reliably due to NFS client caching behavior.
Hence we introduced the option core.trustFolderStat to control if
FileSnapshot can trust File attributes to ensure we don't miss
modifications on NFS. Later more specific options for handling packed
and loose refs were added which also support another config value
AFTER_OPEN, in addition to ALWAYS and NEVER, which refreshes File
attributes by opening a FileInputStream on the file instead of reading
its content and then trusts the File attributes of the refreshed File.
We discussed in jgit-127 how to extend these options for other scenarios
where file attributes are used to detect modifications and came to the
conclusion to improve the existing trustXXX config options in the
following way:
- replace the not well defined "trustFolderStat" option by a general
option "trustStat" which allows to configure all these scenarios with a
single option
- introduce a new enum TrustStat and use it for all scenarios. It has
the values
- NEVER don't trust File attributes
- ALWAYS always trust File attributes
- AFTER_OPEN open a FileInputStream on the respective file or folder
to ensure its File attributes are refreshed and then trust the
refreshed File attributes
- INHERIT only used for specific options to signal it should inherit
its value from the "trustStat" option
- deprecate the old, now unused enums "TrustPackedRefsStat" and
"TrustLooseRefStat"
- deprecate "trustFolderStat", if set, translate it to the corresponding
value of the new option "trustStat"
- if both "trustFolderStat" and "trustStat" are configured the value
configured for "trustStat" takes precedence and "trustFolderStat" is
ignored
- add one specific option for each scenario which can override the
global setting
- add new options "trustLooseObjectStat" and "trustPackStat" which allow
to override the global setting for handling of loose objects and pack
files
- implement option AFTER_OPEN for "trustLooseObjectStat" and
"trustPackStat"
Bug: jgit-127
Change-Id: I662982258bc4494f146805875e52838394673c8f
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This command can be used to optimize storage of references.
For a RefDirectory database, it packs non-symbolic, loose refs into
packed-refs. By default, only the references under '$GIT_DIR/refs/tags'
are packed. The '--all' option can be used to pack all the references
under '$GIT_DIR/refs'.
For Reftable, all refs are compacted into a single table.
Change-Id: I92e786403f8638d35ae3037844a7ad89e8959e02
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Errorprone warns about this deprecated classes. The recommendation is
stop using SecurityManager all together.
The Security Manager is deprecated and subject to removal in a future
release. There is no replacement for the Security Manager. See JEP 411
[1] for discussion and alternatives.
[1] https://openjdk.org/jeps/411
Change-Id: I3c67136e97d13cf24b85e41d94408631c26e8be8
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This is meant to help diagnose LOCK_FAILURE errors, which otherwise provides
very little information in
https://eclipse.googlesource.com/jgit/jgit/+/refs/heads/master/org.eclipse.jgit/src/org/eclipse/jgit/lib/BatchRefUpdate.java#731.
Change-Id: I3d544c899fe66effbd107ea2f38d73f6f253a7e6
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a big API-breaking change cleaning up the signing interfaces.
Initially, these interfaces were GPG/OpenPGP-specific. When EGit added
new signers and signature verifiers that called an external GPG
executable, they were found inadequate and were extended to be able to
pass in the GpgConfig to get access to the "gpg.program" setting.
With the introduction of X.509 S/MIME signing, it was discovered that
the interfaces were still not quite adequate, and the "Gpg" prefix on
the class names were confusing.
Since 7.0 is a major version bump, I'm taking this chance to overhaul
these interfaces from ground up.
For signing, there is a new Signer interface. With it goes a
SignerFactory SPI interface, and a final Signers class managing the
currently set signers. By default, signers for the different signature
types are created from the signer factories, which are discovered via
the ServiceLoader. External code can install its own signers, overriding
the default factories.
For signature verification, exactly the same mechanism is used.
This simplifies the setup of signers and signature verifiers, and makes
it all more regular. Signer instances just get a byte[] to sign and
don't have to worry about ObjectBuilders at all. SignatureVerifier
instances also just get the data and signature as byte[] and don't have
to worry about extracting the signature from a commit or tag, or about
what kind of signature it is.
Both Signers and SignatureVerifiers always get passed the Repository
and the GpgConfig. The repository will be needed in an implementation
for SSH signatures because gpg.ssh.* configs may need to be loaded
explicitly, and some of those values need the current workspace
location.
For signature verification, there is exactly one place in core JGit in
SignatureVerifiers that extracts signatures, determines the signature
type, and then calls the right signature verifier.
Change RevTag to recognize all signature types known in git (GPG, X509,
and SSH).
Change-Id: I26d2731e7baebb38976c87b7f328b63a239760d5
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The existing DfsBlockCache uses a single table for all
extensions (idx, ridx, ...).
This change introduces an implementation of the table
interface that can keep extensions in different cache
tables.
This selects the appropriate cache to use for a specific
PackExt or DfsStreamKey's PackExt type, allowing the
separation of entries from different pack types to help
limit churn in cache caused by entries of differing sizes.
This is especially useful in fine-tuning caches and
influencing interactions by extension type.
For example, a table holding INDEX types only will
not influence evictions of other PackExt types and
vice versa.
The PackExtBlockCacheTable allowing setting the
underlying DfsBlockCacheTables and mappinh directly,
letting users implement and use custom DfsBlockCacheTables.
Change-Id: Icee7b644ef6b600aa473d35645469d6aa1bce345
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The parser reads N integers one by one from the stream, assuming the
InputStream does some ahead reading from storage. We see some very
slow loading of indexes and suspect that this preemptive reading is
not happening. The slow loading can be reproduced in clones, and it
produces higher latencies and locks many threads waiting for the
loading.
Read the whole array from storage in one shot to avoid many small IO
reads. Work directly on the resulting byte[], so there is no need of a
second copy to cast to int/long.
This is how other indexes, like primary or commit graph, work.
Change-Id: I60058606e2c457f60aa4646a1f10ae7b28ce34c2
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse configurations for tables containing a set of extensions,
defined in [core "dfs.*"] sections.
Parse configurations for cache tables according to configurations
defined in [core "dfs.*"] git config sections for sets of
extensions. The current [core "dfs"] is the default to any
extension not listed in any other table.
Configuration falls back to the defaults defined in the
DfsBlockCacheConfig.java file when not set on each cache
table configuration.
Sample format for individual cache tables:
In this example:
1. PACK types would go to the "default" table
2. INDEX and BITMAP_INDEX types would go to the
"multipleExtensionCache" table
3. REFTABLE types would go to the "reftableCache" table
[core "dfs"] // Configuration for the "default" cache table.
blockSize = 512
blockLimit = 100
concurrencyLevel = 5
(...)
[core "dfs.multipleExtensionCache"]
packExtensions = "INDEX BITMAP_INDEX"
blockSize = 512
blockLimit = 100
concurrencyLevel = 5
(...)
[core "dfs.reftableCache"]
packExtensions = "REFTABLE"
blockSize = 512
blockLimit = 100
concurrencyLevel = 5
(...)
Change-Id: I0e534e6d78b684832e3d3d269cee2590aa0f1911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running as a JVM shutdown hook is far too late in an OSGi framework; by
the time the JVM shuts down, the OSGi framework will normally already
have deactivated and unloaded bundles, and thus the JGit cleanup code
may try to work with unloaded classes for which there will be no
classloader anymore.
When JGit is used in an OSGi framework, the cleanups must run on bundle
deactivation, not on JVM shut down.
Add a declarative OSGi service CleanupService. This is a normal Java
class that has no dependencies on any OSGi bundle or interface, but
that is declared in the MANIFEST.MF and in an OSGi Service XML as an
OSGi immediate component. Set the bundle activation policy to "lazy".
(A declarative service is used instead of a bundle activator because the
latter would need to implement the OSGi interface BundleActivator, but
JGit should not have dependencies on OSGi.)
When JGit runs in an OSGi framework, the framework will create an
instance of CleanupService through the no-args constructor when (and
before) the first class from this bundle is loaded. This instance thus
knows that it is operating in OSGi, and will run the ShutdownHook when
the bundle is deactivated: bundle deactivation will deactivate the
CleanupService instance.
When JGit does not run in an OSGi framework, the OSGi service
declaration will be ignored, and there will be no already existing
CleanupService instance. We create one lazily, which thus knows that
it is not operating in OSGi, and which will use a JVM shutdown hook to
run the ShutdownHook.
This also reverts commit e6d83d61eade6dee223757d149a4df9650752a55.
Bug: jgit-36
Change-Id: I9c621b0707453c087f638974312ea1bf8ec30c31
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
| |\
| |
| |
| |
| |
| |
| |
| | |
* stable-6.8:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I08095dfaefb963876d993383cb35acc6b75d7691
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-6.7:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I01749bae6f46d1a8ebd25b890e667cc092f3a659
|
| | | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.6:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I2bbc8c9a4ed45d37fa7ba63b2afd5511b6cf47a2
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When the bitmap file was created *after* a packfile had been
loaded into the memory, JGit was unable to discover them.
That happed because of two problems:
1. The PackDirectory.getPacks() does not implement the usual
while loop that is scanning through the packs directory
as in the other parts of JGit.
2. The scan packs does not look for newly created bitmap files
if the packfile is already loaded in memory.
Implement the normal packfiles scanning whenever the PackDirectory
needs to return a list of packs, and make sure that any reused
Pack object would have its associated bitmap properly refreshed
from disk.
Adapt the assertions in GcConcurrentTest with the rescanned list
of Pack from the objects/packs directory.
Bug: jgit-15
Change-Id: I2ed576cefd78a0e128b175228a59c9af51523d7b
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During shutdown the JGitText class may already be unloaded causing
NoClassDefFoundError.
Bug: jgit-17
Change-Id: I657b5a508efc8b3778be346d640f4e4d69abd5c5
|
| |\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-6.7:
Introduce a PriorityQueue sorting RevCommits by commit timestamp
Remove org.eclipse.jgit.benchmark/.factorypath
Update jmh to 1.37 for org.eclipse.jgit.benchmark
Change-Id: I5d49a9dc7da17b83243229d4d8d3b9ee0a063e65
|
| | |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-6.6:
Introduce a PriorityQueue sorting RevCommits by commit timestamp
Remove org.eclipse.jgit.benchmark/.factorypath
Update jmh to 1.37 for org.eclipse.jgit.benchmark
Change-Id: I76ebca527e523f124bfe81c821169c790eddccb6
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The DateRevQueue uses a tailor-made algorithm to keep
RevCommits sorted by reversed commit timestamp, which has a O(n*n/2)
complexity and caused the explosion of the Git fetch times to
tens of seconds.
The standard Java PriorityQueue provides a O(n*log(n)) complexity
and scales much better with the increase of the number of
RevCommits.
Introduce a new implementation DateRevPriorityQueue of the DateRevQueue
based on PriorityQueue.
Enable usage of the new DateRevPriorityQueue implementation by setting
the system property REVWALK_USE_PRIORITY_QUEUE=true. By default the old
implementation DateRevQueue is used.
Benchmark results:
```
(numCommits) (usePriorityQueue) Mode Cnt Score Error Units
5 true avgt 10 39,4 ± 6,1 ns/op
5 false avgt 10 14,1 ± 2,2 ns/op
10 true avgt 10 29,7 ± 3,5 ns/op
10 false avgt 10 13,2 ± 2,0 ns/op
50 true avgt 10 50,4 ± 5,3 ns/op
50 false avgt 10 18,6 ± 0,2 ns/op
100 true avgt 10 58,3 ± 5,0 ns/op
100 false avgt 10 20,5 ± 0,8 ns/op
500 true avgt 10 51,7 ± 2,6 ns/op
500 false avgt 10 43,3 ± 0,5 ns/op
1000 true avgt 10 49,2 ± 2,4 ns/op
1000 false avgt 10 62,7 ± 0,2 ns/op
5000 true avgt 10 48,8 ± 1,5 ns/op
5000 false avgt 10 228,3 ± 0,5 ns/op
10000 true avgt 10 44,2 ± 0,9 ns/op
10000 false avgt 10 377,6 ± 2,7 ns/op
50000 true avgt 10 50,3 ± 1,6 ns/op
50000 false avgt 10 637,0 ± 111,8 ns/op
100000 true avgt 10 61,8 ± 4,4 ns/op
100000 false avgt 10 965,1 ± 268,0 ns/op
500000 true avgt 10 127,2 ± 7,9 ns/op
500000 false avgt 10 9610,2 ± 184,8 ns/op
```
Memory allocation results:
```
Number of commits loaded: 850 000
Custom implementation: 378 245 120 Bytes
Priority queue implementation: 340 495 616 Bytes
```
Bug: 580137
Change-Id: I8b33df6e9ee88933098ecc81ce32bdb189715041
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
|
| | | |
| | |
| | |
| | | |
Change-Id: I5189e966aecc57fe7c3e6c3f7f8e6b16917ee27f
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bloom filter computation can be an expensive process and right now it
is invisible to the user.
Report progress while calculating bloom filters.
Log of GC with bloom filter enabled:
Computing commit-graph path bloom filters: 100% (9551/9551)
Computing commit-graph generation numbers: 100% (9551/9551)
Writing out commit-graph: 100% (9551/9551)
Change-Id: Ife65e63ac2c37d064d5f049a366cbb52c3ef6798
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ProgressMonitor task to track the calculation of generation
numbers is nested inside the task that follows the writing of all
lines in the commit-graph. ProgressMonitor doesn't support nested
tasks and this confuses the counting.
Move the start/end of the "writing commit graph" task to the
writeCommitData section, after calculating the generation
numbers. Make that task track by commits instead of by lines.
Moving the start/end of the progress task to the chunk-writing
functions is clearer and easier to extend.
Logging of GC before:
Writing out commit-graph in 3 passes: 51% ( 9807/19358)
Computing commit-graph generation numbers: 100% (9551/9551)
Logging of GC after:
Computing commit-graph generation numbers: 100% (9551/9551)
Writing out commit-graph: 100% (9551/9551)
Change-Id: I87d69c06c9a3c7e75be12b6f0d1a63b5924e298a
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the exception is thrown, we don't know if it is because the
stream didn't have data or had a wrong header.
Log the read bytes to differentiate these cases.
Change-Id: Ie7612eab39016f5ad7f1bfb2e07cab972dab796f
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When multiple branches were to be removed, the git config was updated
after each and every branch. Newly do so only once at the end, after all
branches have been deleted.
Because there may be an exception after some branches have already been
deleted, take care to update the config even if an exception is thrown.
Bug: 451508
Change-Id: I645be8a1a59a1476d421e46933c3f7cbd0639fec
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This way we can avoid to access the byte buffers backing array.
Implement a ByteBufferInputStream to wrap a byte buffer which we can use
to expose the filter result as an input stream.
Change-Id: I461c82090de2562ea9b649b3f953aad4571e3d25
|
| | | |
| | |
| | |
| | | |
Change-Id: I35c3a3baadb8d7d73c01252fe4333fa2159722ee
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This should avoid stale lock files if the JVM is terminated gracefully.
Implement a ShutdownHook which can register/unregister listeners which
need to do some cleanup during graceful JVM shutdown. This hook is
registered as a Java shutdown hook and when the JVM shuts down
calls #onShutdown of registered listeners using a parallel stream
to let them run concurrently.
See https://docs.oracle.com/javase/8/docs/technotes/guides/lang/hook-design.html
Bug: 582379
Change-Id: I1621dc5f7d9a8c832b6d1b74cbc47578b1c2f0b8
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
* stable-6.6:
Prepare 6.6.2-SNAPSHOT builds
JGit v6.6.1.202309021850-r
Checkout: better directory handling
Change-Id: Ice82d68b2d343a5fac214807cdb369e486481aab
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When checking out a file into the working tree ensure that all parent
directories of the file below the working tree root are actually
directories and do exist before we try to create the file.
When multiple files are to be checked out (or even a whole tree), this
may check the same directories over and over again. Asking the file
system every time for file attributes is a potentially expensive
operation. As a remedy, introduce an in-memory cache of directory
states for a particular check-out operation.
Apply the same fix also in the ResolveMerger, which may also check out
files, and also in the PatchApplier. In PatchApplier, also validate
paths.
Change-Id: Ie12864c54c9f901a2ccee7caddec73027f353111
Signed-off-by: Thomas Wolf <twolf@apache.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new version 1 file-based reverse index has a footer with the
checksum of the corresponding pack file and a checksum of its own
contents. The initial implementation doesn't enforce that the pack
checksum matches the checksum found in the forward index nor that the
self checksum matches the contents of the file just read in.
Offer a method for reverse index users to verify the checksums in a way
appropriate to the version being used. For the pre-existing computed
version, always succeed since it is not based on a file so there is no
possibility of corruption.
Check for corruption of the file itself during parsing the checksum
footer, by comparing the self checksum with the digest of the file
contents read.
Change-Id: I87ff3933cf1afa76663350400b616695e4966cb6
Signed-off-by: Anna Papitto <annapapitto@google.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reverse index for a pack is used to quickly find an object's
position in the pack's forward index based on that object's pack offset.
It is currently computed from the forward index by sorting the index
entries by the corresponding pack offset. This computation uses
insertion sort, which has an average runtime of O(n^2).
Cgit persists a pack reverse index file
to avoid recomputing the reverse index ordering. Instead they write a
file with format
https://git-scm.com/docs/pack-format#_pack_rev_files_have_the_format
which can later be read and parsed into the in-memory reverse index
each time it is needed.
PackReverseIndexV1 parses a reverse index file with the official
version 1 format into an in-memory representation of the reverse index
which implements methods to find an object's forward index position
from its offset in logorithmic time.
Change-Id: I60a92463fbd6a8cc9c1c7451df1c14d0a21a0f64
Signed-off-by: Anna Papitto <annapapitto@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reverse index for a pack is used to quickly find an object's
position in the pack's forward index based on that object's pack offset.
It is currently computed from the forward index by sorting the index
entries by the corresponding pack offset. This computation uses
bucket sort with insertion sort, which has an average runtime of
O(n log n) and worst case runtime of O(n^2); and memory usage of
3*size(int)*n because it maintains 3 int arrays, even after sorting is
completed. The computation must be performed every time that the reverse
index object is created in memory.
In contrast, Cgit persists a pack reverse index file to avoid
recomputing the reverse index ordering every time that it is needed.
Instead they write a file with format
https://git-scm.com/docs/pack-format#_pack_rev_files_have_the_format
which can later be read and parsed into an in-memory reverse index each
time it is needed.
Introduce these reverse index files to JGit. PackReverseIndexWriter
writes out a reverse index file to be read later when needed. Subclass
PackReverseIndexWriterV1 writes a file with the official version 1
format.
To avoid temporarily allocating an Integer collection while sorting and
writing out the contents, using memory 4*size(Integer)*n, use an
IntList and its #sort method, which uses quicksort.
Change-Id: I6437745777a16f723e2f1cfcce4e0d94e599dcee
Signed-off-by: Anna Papitto <annapapitto@google.com>
|
| |
|
|
|
| |
Change-Id: Ia3ec0ce1af65114b48669157a934f70f1e22fd37
Bug: Google b/271474227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. For general errors, throw IOException instead of wrapping them with
PatchApplyException. The wrapping was moved (back) to ApplyCommand.
2. For file specific errors, log the errors as part of
PatchApplier::Result.
3. Change applyPatch() to receive the parsed Patch object, so the caller
can decide how to handle parsing errors.
Background: this utility class was extracted from ApplyCommand on V6.4.0.
During the extraction, we left the exception wrapping by
PatchApplyException intact. This attitude made it harder for the callers to
distinguish between the actual error causes.
Change-Id: Ib0f2b5e97a13df2339d8b65f2fea1c819c161ac3
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
* stable-6.4:
Use Java 11 ProcessHandle to get pid of the current process
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: Ifa4e56b6ecca9305f3f1685e45450019bfc82e22
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-6.3:
Use Java 11 ProcessHandle to get pid of the current process
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: Ic40dbab18616d8d9fe3820b9890c86652b80eb47
|
| | | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.2:
Use Java 11 ProcessHandle to get pid of the current process
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: I53cf9675deac0b588048d8224216d2a7e8bd16ec
|
| | | | |\
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.1:
Use Java 11 ProcessHandle to get pid of the current process
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: I0562a4a224779ccf1e4cc1ff8f5a352e55ab220a
|
| | | | | |\
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* stable-6.0:
Use Java 11 ProcessHandle to get pid of the current process
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: Ib9a2419253ffcbc90874adbfdb8129fee3178210
|
| | | | | | |\
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* stable-5.13:
Acquire file lock "gc.pid" before running gc
Silence API errors introduced by 9424052f
Change-Id: Ibb5c46cb79377d2d2cd7d4586f31c86665d2851c
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Git guards gc by locking a lock file "gc.pid" before starting execution.
The lock file contains the pid and hostname of the process holding the
lock. Git tries to kill the process holding that lock if the lock file
wasn't modified in the last 12 hours and was started from the same host.
Teach JGit to acquire this lock before running gc but skip execution if
another process already holds the lock. Killing the other process could
be undesired if it's a long running application.
If the lock file wasn't modified in the last 12 hours try to lock it and
run gc if locking succeeds.
Register a shutdown hook for the lock file to ensure it is cleaned up if
the process is gracefully killed.
Change-Id: I00b838dcbf4fb0d03863bf7a2cd86b743c6c6971
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Change-Id: I81bb78344df61e6eb42622fcef6235d4da0ae052
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
JGit knows how to read/write commit graphs but the DFS stack is not
using it yet.
The DFS garbage collector generates a commit-graph with commits
reachable from any ref. The pack is stored as extra stream in the GC
pack. DfsPackFile mimicks how other indices are loaded storing the
reference in DFS cache.
Signed-off-by: Xing Huang <xingkhuang@google.com>
Change-Id: I3f94997377986d21a56b300d8358dd27be37f5de
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
A ternary search tree is a type of tree where nodes are arranged in a
manner similar to a binary search tree, but with up to three children
rather than the binary tree's limit of two.
Each node of a ternary search tree stores a single character, a
reference to a value object and references to its three children named
equal kid, lo kid and hi kid. The lo kid pointer must point to a node
whose character value is less than the current node. The hi kid pointer
must point to a node whose character is greater than the current
node.[1] The equal kid points to the next character in the word. Each
node in a ternary search tree represents a prefix of the stored strings.
All strings in the middle subtree of a node start with that prefix.
Like other prefix trees, a ternary search tree can be used as an
associative map with the ability for incremental string search. Ternary
search trees are more space efficient compared to standard prefix trees,
at the cost of speed.
They allow efficient prefix search which is important to implement
searching refs by prefix in a RefDatabase.
Searching by prefix returns all keys if the prefix is an empty string.
Bug: 576165
Change-Id: If160df70151a8e1c1bd6716ee4968e4c45b2c7ac
|
