Skip to main content
AgeCommit message (Collapse)AuthorFilesLines
2019-04-15Prepare 4.5.8-SNAPSHOT buildsstable-4.5Matthias Sohn56-302/+302
Change-Id: I70628cb8fcad0a60598dc937abbed63606a78599 Signed-off-by: Matthias Sohn <>
2019-04-15JGit v4.5.7.201904151645-rv4.5.7.201904151645-rMatthias Sohn56-59/+59
Change-Id: I3e32cf13f5cb99d8e570412d80d941740399c07d Signed-off-by: Matthias Sohn <>
2019-04-11Remember the cause for invalidating a packfileLuca Milanesio5-23/+76
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 <> Signed-off-by: David Pursehouse <> Signed-off-by: Matthias Sohn <>
2019-04-10Fix API problem filtersMatthias Sohn2-24/+1
Change-Id: I96e0ddc34251348ec4877c9d94b045eb1c53e758 Signed-off-by: Matthias Sohn <>
2019-04-09Fix pack files scan when filesnapshot isn't modifiedLuca Milanesio2-6/+54
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 <> Signed-off-by: Matthias Sohn <>
2019-03-12Prepare 4.5.7-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: I5c275c542e12746c3d8ecf8462791969f9e89e12 Signed-off-by: Matthias Sohn <>
2019-03-12JGit v4.5.6.201903121547-rv4.5.6.201903121547-rMatthias Sohn56-59/+59
Change-Id: I5a071ed10e1ac1ab28f992d45cde335c12556a80 Signed-off-by: Matthias Sohn <>
2019-03-12Check for packfile validity and fd before readingLuca Milanesio1-0/+8
When reading from a packfile, make sure that is valid and has a non-null file-descriptor. Because of concurrency between a thread invalidating a packfile and another trying to read it, the read() may result into a NPE that won't be able to be automatically recovered. Throwing a PackInvalidException would instead cause the packlist to be refreshed and the read to eventually succeed. Bug: 544199 Change-Id: I27788b3db759d93ec3212de35c0094ecaafc2434 Signed-off-by: Luca Milanesio <>
2019-03-12Move throw of PackInvalidException outside the catchLuca Milanesio1-2/+3
When a packfile is invalid, throw an exception explicitly outside any catch scope, so that is not accidentally caught by the generic catch-all cause, which would set the packfile as valid again. Flagging an invalid packfile as valid again would have dangerous consequences such as the corruption of the in-memory packlist. Bug: 544199 Change-Id: If7a3188a68d7985776b509d636d5ddf432bec798 Signed-off-by: Luca Milanesio <>
2019-03-12Use FileSnapshot to get lastModified on PackFileLuca Milanesio1-1/+1
Do not redundantly call File.lastModified() for extracting the timestamp of the PackFile but rather use consistently the FileSnapshot which reads all file attributes in a single bulk call. Change-Id: I932675ae4fe56dcd3833dac249816f097303bb09 Signed-off-by: Luca Milanesio <> Signed-off-by: Matthias Sohn <>
2019-03-12Include size when comparing FileSnapshotLuca Milanesio5-9/+107
Due to finite filesystem timestamp resolution the last modified timestamp of files cannot detect file changes which happened in the immediate past (less than one filesystem timer tick ago). Read and consider file size also, so that differing file size can help to more accurately detect file changes without reading the file content. Use bulk read to avoid multiple stat calls to retrieve file attributes. Change-Id: I974288fff78ac78c52245d9218b5639603f67a46 Signed-off-by: Luca Milanesio <> Signed-off-by: Matthias Sohn <>
2019-03-12Do not reuse packfiles when changed on filesystemLuca Milanesio2-2/+15
The pack reload mechanism from the filesystem works only by name and does not check the actual last modified date of the packfile. This lead to concurrency issues where multiple threads were loading and removing from each other list of packfiles when one of those was failing the checksum. Rely on FileSnapshot rather than directly checking lastModified timestamp so that more checks can be performed. Bug: 544199 Change-Id: I173328f29d9914007fd5eae3b4c07296ab292390 Signed-off-by: Luca Milanesio <>
2019-03-12Silence API warnings for new API introduced for fixesMatthias Sohn1-0/+14
Change-Id: I3ea7ff2efd33ca6c780afaef9010cec82780d7fa Signed-off-by: Matthias Sohn <>
2018-12-24Prepare 4.5.6-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: I57c55187ada6d824b94a17f5a79a5bcff61f9ee9 Signed-off-by: Matthias Sohn <>
2018-12-24JGit v4.5.5.201812240535-rv4.5.5.201812240535-rMatthias Sohn56-59/+59
Change-Id: I6e89e937c08757887967d91afb39cfbe8372d6b5 Signed-off-by: Matthias Sohn <>
2018-12-24Call AdvertiseRefsHook before validating wantsMasaya Suzuki1-13/+9
AdvertiseRefsHook is used to limit the visibility of the refs in Gerrit. If this hook is not called, then all refs are treated as visible, causing the server to serve commits reachable from branches the client should not be able to access, if asked to via a request naming a guessed object id. This bug was introduced in v2.0.0.201206130900-r~123 (Modify refs in UploadPack/ReceivePack using a hook interface, 2012-02-08). Stateful bidirectional transports are not affected. Fix it by moving the AdvertiseRefsHook call to getAdvertisedOrDefaultRefs, ensuring the hook is called in all cases. [jn: backported to stable-4.5 by splitting out tests and the protocol v2 specific parts] Change-Id: I159f396216354f2eda3968d17802e166d8c8ec2d Signed-off-by: Masaya Suzuki <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Matthias Sohn <>
2018-10-19Merge branch 'stable-4.4' into stable-4.5David Pursehouse0-0/+0
* stable-4.4: Prepare 4.4.2-SNAPSHOT builds JGit v4.0.3.201509231615-r Change-Id: Icd66a796b0cce93c75a52cc77fec8f9df3eeccb4 Signed-off-by: David Pursehouse <>
2018-10-19Merge branch 'stable-4.3' into stable-4.4stable-4.4David Pursehouse0-0/+0
* stable-4.3: JGit v4.0.3.201509231615-r Change-Id: I147d81a9cc9c0f9e66084897df9c88c369539db7 Signed-off-by: David Pursehouse <>
2018-10-19Merge branch 'stable-4.2' into stable-4.3stable-4.3David Pursehouse0-0/+0
* stable-4.2: JGit v4.0.3.201509231615-r Change-Id: Ic90ef74497afee9da4b49dcb53302b4efa5b9f26 Signed-off-by: David Pursehouse <>
2018-10-19Merge branch 'stable-4.1' into stable-4.2stable-4.2David Pursehouse0-0/+0
* stable-4.1: JGit v4.0.3.201509231615-r Change-Id: I6cc5bcefad2e8dee3394770d36608f981bfc9a9e Signed-off-by: David Pursehouse <>
2018-10-19Merge branch 'stable-4.0' into stable-4.1stable-4.1David Pursehouse0-0/+0
* stable-4.0: JGit v4.0.3.201509231615-r Change-Id: Ie74b0392ef145ffd27dc903c45f7fec2d4492a17 Signed-off-by: David Pursehouse <>
2018-10-13Replace Findbugs with Spotbugs in org.eclipse.jgit/pom.xmlDavid Pursehouse1-2/+2
Change-Id: If9cb0de7a0e7bd95eac7daeee140a18385192a48 Signed-off-by: David Pursehouse <>
2018-10-09Replace FindBugs with SpotBugsDavid Pursehouse1-8/+9
SpotBugs [1] is the spiritual successor of FindBugs, carrying on from the point where it left off with support of its community. This is a backport of [1] which originally did the replacement on the master branch. This change updates to the current latest version, so that we can get the benefit of its checks when pushing changes to the stable branches. [1] [2] Change-Id: Ib73d56b5980b55f4d7e09d87abec3138cac3d3dc Signed-off-by: David Pursehouse <>
2018-06-19Temporarily @Ignore flaky CommitCommandTest methodsDave Borowitz1-0/+3
Change-Id: Ia2c42d014323bd29b85bf76f1a20c83f612406d7 Signed-off-by: David Pursehouse <> (cherry picked from commit e93b0026ced10c956e76daed038f2560a33b5baf)
2018-05-10Retry stale file handles on .git/config fileNasser Grainawi3-31/+56
On a local non-NFS filesystem the .git/config file will be orphaned if it is replaced by a new process while the current process is reading the old file. The current process successfully continues to read the orphaned file until it closes the file handle. Since NFS servers do not keep track of open files, instead of orphaning the old .git/config file, such a replacement on an NFS filesystem will instead cause the old file to be garbage collected (deleted). A stale file handle exception will be raised on NFS clients if the file is garbage collected (deleted) on the server while it is being read. Since we no longer have access to the old file in these cases, the previous code would just fail. However, in these cases, reopening the file and rereading it will succeed (since it will open the new replacement file). Since retrying the read is a viable strategy to deal with stale file handles on the .git/config file, implement such a strategy. Since it is possible that the .git/config file could be replaced again while rereading it, loop on stale file handle exceptions, up to 5 extra times, trying to read the .git/config file again, until we either read the new file, or find that the file no longer exists. The limit of 5 is arbitrary, and provides a safe upper bounds to prevent infinite loops consuming resources in a potential unforeseen persistent error condition. Change-Id: I6901157b9dfdbd3013360ebe3eb40af147a8c626 Signed-off-by: Nasser Grainawi <> Signed-off-by: Matthias Sohn <>
2017-11-22Prepare 4.5.5-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: I71f946f2875716670a2d74c21a8ab38a1f53a25c Signed-off-by: Matthias Sohn <>
2017-11-22JGit v4.5.4.201711221230-rv4.5.4.201711221230-rMatthias Sohn56-59/+59
Change-Id: Ia1079da239c5b3fde1ba8d2acc4e465a46297b4d Signed-off-by: Matthias Sohn <>
2017-11-22Fix LockFile semantics when running on NFSChristian Halstrick5-3/+127
When running on NFS there was a chance that JGits LockFile semantic is broken because File#createNewFile() may allow multiple clients to create the same file in parallel. This change provides a fix which is only used when the new config option core.supportsAtomicCreateNewFile is set to false. The default for this option is true. This option can only be set in the global or the system config file. The repository config file is not taken into account in this case. If the config option core.supportsAtomicCreateNewFile is true then File#createNewFile() is trusted and the behaviour doesn't change. But if core.supportsAtomicCreateNewFile is set to false then after successful creation of the lock file a hardlink to that lock file is created and the attribute nlink of the lock file is checked to be 2. If multiple clients manage to create the same lock file nlink would be greater than 2 showing the error. This expensive workaround is described in section III.d) "Exclusive File Creation" Change-Id: I3d2cc48d8eb280d5f7039eb94da37804f903be6a
2017-11-21Honor trustFolderStats also when reading packed-refsChristian Halstrick1-2/+9
Then list of packed refs was cached in RefDirectory based on mtime of the packed-refs file. This may fail on NFS when attributes are cached. A cached mtime of the packed-refs file could cause JGit to trust the cached content of this file and to overlook that the file is modified. Honor the config option trustFolderStats and always read the packed-refs content if the option is false. By default this option is set to true and this fix is not active. Change-Id: I2b65cfaa8f4aba2efbf8a5e865d3f09f927e2eec
2017-08-26Prepare 4.5.4-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: Id8b902bf2bf590b41f2e246c5ecf1592e1c411f2 Signed-off-by: Matthias Sohn <>
2017-08-16JGit v4.5.3.201708160445-rv4.5.3.201708160445-rMatthias Sohn56-59/+59
Change-Id: I2d57144976e3683e180d3a42edc6c3bf2905e87c Signed-off-by: Matthias Sohn <>
2017-08-14Fix exception handling for opening bitmap index filesChristian Halstrick2-2/+114
When creating a new PackFile instance it is specified whether this pack has an associated bitmap index file or not. This information is cached and the public method getBitmapIndex() will always assume a bitmap index file must exist if the cached data tells so. But it may happen that the packfiles are repacked during a gc in a different process causing the packfile, bitmap-index and index file to be deleted. Since JGit still has an open FileHandle on the packfile this file is not really deleted and can still be accessed. But index and bitmap index file are deleted. Fix getBitmapIndex() to invalidate the cached packfile instance if such a situation occurs. This problem showed up when a gerrit server was serving repositories which where garbage collected with native git regularly. Fetch and clone commands for certain repositories failed permanently after a native git gc had deleted old bitmap index files. Change-Id: I8e620bec74dd3f310ba42024f9a657062f868f0e Signed-off-by: Matthias Sohn <>
2017-04-07Prepare 4.5.3-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: I69681b7a5687ca76bd0dd5d3e7ce2cff841d0e32 Signed-off-by: Matthias Sohn <>
2017-04-07JGit v4.5.2.201704071617-rv4.5.2.201704071617-rMatthias Sohn56-59/+59
Change-Id: I66402643d7c84c90bf5cefed4d2ec3aa68c94cfb Signed-off-by: Matthias Sohn <>
2017-03-26Only mark packfile invalid if exception signals permanent problemMatthias Sohn6-18/+245
Add NoPackSignatureException and UnsupportedPackVersionException to explicitly mark permanent unrecoverable problems with a pack Assume problem with a pack is permanent only if we are sure the exception signals a non-transient problem we can't recover from: - AccessDeniedException: we lack permissions - CorruptObjectException: we detected corruption - EOFException: file ended unexpectedly - NoPackSignatureException: pack has no pack signature - NoSuchFileException: file has gone missing - PackMismatchException: pack no longer matches its index - UnpackException: unpacking failed - UnsupportedPackIndexVersionException: unsupported pack index version - UnsupportedPackVersionException: unsupported pack version Do not attempt to handle Errors since they are thrown for serious problems applications should not try to recover from. Change-Id: I2c416ce2b0e23255c4fb03a3f9a0ee237f7a484a Signed-off-by: Matthias Sohn <>
2017-03-25Don't flag a packfile invalid if opening existing file failedLuca Milanesio1-0/+7
A packfile random file open operation may fail with a FileNotFoundException even if the file exists, possibly for the temporary lack of resources. Instead of managing the FileNotFoundException as any generic IOException it is best to rethrow the exception but prevent the packfile for being flagged as invalid until it is actually opened and read successfully or unsuccessfully. Bug: 514170 Change-Id: Ie37edba2df77052bceafc0b314fd1d487544bf35 Signed-off-by: Luca Milanesio <> Signed-off-by: Matthias Sohn <>
2017-03-25Prepare 4.5.2-SNAPSHOT buildsMatthias Sohn56-302/+302
Change-Id: I8485de1f3f63dc9ec445b8fb08093ca144aedc59 Signed-off-by: Matthias Sohn <>
2017-03-20JGit v4.5.1.201703201650-rv4.5.1.201703201650-rMatthias Sohn56-59/+59
Change-Id: I88de7c9f52abbc4921a82208ed74d22aa19fb3cd Signed-off-by: Matthias Sohn <>
2017-03-15Don't remove pack when FileNotFoundException is transientLuca Milanesio3-9/+40
The FileNotFoundException is typically raised in three conditions: 1. file doesn't exist 2. incompatible read vs. read/write open modes 3. filesystem locking 4. temporary lack of resources (e.g. too many open files) 1. is already managed, 2. would never happen as packs are not overwritten while with 3. and 4. it is worth logging the exception and retrying to read the pack again. Log transient errors using an exponential backoff strategy to avoid flooding the logs with the same error if consecutive retries to access the pack fail repeatedly. Bug: 513435 Change-Id: I03c6f6891de3c343d3d517092eaa75dba282c0cd Signed-off-by: Luca Milanesio <> Signed-off-by: Matthias Sohn <>
2016-12-13Fix one case of missing objectHector Oswaldo Caballero1-3/+8
When a repository is being GCed and a concurrent push is received, there is the possibility of having a missing object. This is due to the fact that after the list of objects to delete is built, there is a window of time when an unreferenced and ready to delete object can be referenced by the incoming push. In that case, the object would be deleted because there is no way to know it is no longer unreferenced. This will leave the repository in an inconsistent state and most of the operations fail with a missing tree/object error. Given the incoming push change the last modified date for the now referenced object, verify this one is still a candidate to delete before actually performing the delete operation. Change-Id: Iadcb29b8eb24b0cb4bb9335b670443c138a60787 Signed-off-by: Hector Oswaldo Caballero <>
2016-11-24Use the same variable to check and extract LFS object idJacek Centkowski1-2/+3
It is easier to maintain when the same variable is used for both check and extraction of LFS object id. Change-Id: I5406f9bc4a085aa164c4565a9667ad2925105190 Signed-off-by: Jacek Centkowski <>
2016-10-19Config: do not add spaces before unitsDavid Turner1-3/+3
Adding a space before the unit ('g', 'm', 'k) causes git to fail with the error: fatal: bad numeric config value Change-Id: I57f11d3a1cdcca4549858e773af1a2a80fc0369f Signed-off-by: David Turner <> Signed-off-by: David Pursehouse <>
2016-10-13Unconditionally close repositories in RepositoryCache.clear()Matthias Sohn1-9/+3
Earlier we tried to close the repository before removing it from the cache, so close only reduced refcount but didn't close it. Now that we no longer leak usage count on purpose and the usage count is now ignored anyway, there is no longer a need to run the removal twice. Change-Id: I8b62cec6d8a3e88c096d1f37a1f7f5a5066c90a0 Signed-off-by: Matthias Sohn <>
2016-10-12Fix eviction of repositories with negative usage countHugo Arès2-1/+22
If the repository close method was called twice (or more) for one open, the usage count became negative and the repository was never be evicted from the cache because the method checking if repository is expired was not considering negative usage count. Change-Id: I18a80c415c54c37d1b9def2b311ff2d0afa455ca Signed-off-by: Hugo Arès <>
2016-10-01pgm: Fix misspelled key of an externalized stringMatthias Sohn1-1/+1
Bug: 502107 Change-Id: I76d0981c8463b63bd049f50cdc7d549fa0604b3c Signed-off-by: Matthias Sohn <>
2016-10-01Add missing online help for Ketch server type option in CLI daemonMatthias Sohn2-1/+3
Change-Id: I19d27bbdbfdb1c7a5a688e41dfcba73a142a1afd Signed-off-by: Matthias Sohn <>
2016-10-01Remove wrong junit dependencies in org.eclipse.jgit.pgmMatthias Sohn1-11/+0
Bug: 503010 Change-Id: I8fa99f53020af41eb15c1f63b6f3ba094d56bfef Signed-off-by: Matthias Sohn <>
2016-09-24Merge "Fix carrying over flags during a RevWalk" into stable-4.5Shawn Pearce2-1/+147
2016-09-23Fix carrying over flags during a RevWalkChristian Halstrick2-1/+147
There was a bug when carrying over flags from a merge commit to its non-first parents. The first parent of a merge commit was handled differently and correct but the non-first parents are handled by a recursive algorithm. Flags should be copied from the root merge commit to parent-2, to grandparent-2, ... up to the limit of STACK_DEPTH==500 parents-levels. But the recursive algorithm was always copying only to the direct parents of the merge commit and not the grand*-parents. This seems to be no problem when commits are handled in a strict date order because then copying only one level is no problem if children are handled before parents. But when commits are not seperated anymore by distinctive correct dates (e.g. because all commits have the same date) then it may happen that a merge-parent is handled before the merge commit and when dealing later with the merge commit one has to copy flags down to more than one level Bug: 501211 Change-Id: I2d79a7cf1e3bce21a490905ccd9d5e502d7b8421
2016-09-21Turn off doclint also during Maven site generationMatthias Sohn1-0/+11
Change-Id: Iefc77114de21e7a101642f5c3a8f0fb317886ba2 Signed-off-by: Matthias Sohn <>

Back to the top