summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ObjectDownloadListener#onWritePossible: Add comment on return statementDavid Ostrovsky2018-09-251-0/+4
| | | | | | | | | It is not obvious why this return statement is needed. Clarify with a comment that otherwise endless loop may show up when recent versions of Jetty are used. Change-Id: I8e5d4de51869fb1179bf599bfb81bcd7d745874b Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* Prepare 4.7.5-SNAPSHOT buildsMatthias Sohn2018-09-1856-321/+321
| | | | | Change-Id: Ifce4311fe9429d751cec5b326b540d6233762153 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.7.4.201809180905-rv4.7.4.201809180905-rMatthias Sohn2018-09-1856-59/+59
| | | | | Change-Id: Iceee69df5fd593bece4532d5781e3771f5761ef8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Update API problem filterMatthias Sohn2018-09-181-1/+1
| | | | Change-Id: Ie15c7d0b320f75915c362f5bd3bd6b39d84a900a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix ObjectUploadListener#closeMatthias Sohn2018-09-181-1/+3
| | | | | | Do not try to set response status if response is already committed. Change-Id: I9a7c2871c86eb53416b905324775f3ed961c8ae6 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix error handling in FileLfsServletMatthias Sohn2018-09-171-0/+5
| | | | | | | | | | | | | | | | | | | Check in #sendError method if the response was committed already. If yes we cannot set response status or send an error message, last resort is to close the outputstream. If the response wasn't yet committed first reset the response before using writer to send the error message to the client since mixing STREAM and WRITE mode (mixing asynchronous and blocking I/O) is illegal in servlet 3.1. see the following bugs in the gerrit and jetty issue trackers https://bugs.chromium.org/p/gerrit/issues/detail?id=9667 https://bugs.chromium.org/p/gerrit/issues/detail?id=9721 https://github.com/eclipse/jetty.project/issues/2911 Change-Id: Ie35563c2e0ac1c5e918185a746622589a880dc7f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ObjectDownloadListener#onWritePossible: Make code spec compatibleDavid Ostrovsky2018-09-171-13/+19
| | | | | | | | | | | | | | Current code violates the ServletOutputStream contract. For every out.isReady() == true either write or close of that ServletOutputStream should be called. See also this issue upstream for more context: [1]. [1] https://github.com/eclipse/jetty.project/issues/2911 Change-Id: Ied575f3603a6be0d2dafc6c3329d685fc212c7a3 Signed-off-by: David Ostrovsky <david@ostrovsky.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ObjectDownloadListener: Return from onWritePossible when data is writtenDavid Ostrovsky2018-09-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | When buffer was written not only call AsyncContext#complete() but also return from the ObjectDownloadListener#onWritePossible(). This avoids endless loop after upgrading from Jetty 9.3.x to 9.4.x lines. In Jetty example implementation:[1] the return statemnt is also used: // If we are at EOF then complete   if (len < 0)   {    async.complete();     return;   } See also this issue upstream: [2]. [1] https://webtide.com/servlet-3-1-async-io-and-jetty [2] https://github.com/eclipse/jetty.project/issues/2911 Change-Id: Iac73fb25e67d40228a378a8e34103f1d28b72a76 Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* Fix IOException when LockToken#close failsMatthias Sohn2018-09-151-7/+12
| | | | | | | This happened if the LockTokens hard link was already deleted earlier. Bug: 531759 Change-Id: Idc84bd695fac1a763b3cbb797c9c4c636a16e329 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix NoSuchFileException during directory cleanup in RefDirectoryMatthias Sohn2018-09-121-1/+1
| | | | | | | | Bug: 538285 Change-Id: Iab5c381a412cb2c2176af55189668c267ed29fbc Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> (cherry picked from commit 8ab89ef066f91a7d39b705f4e61498f37291ffab) Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Externalize warning message in RefDirectory.delete()Matthias Sohn2018-09-113-1/+4
| | | | | | | Change-Id: Icec16c01853a3f5ea016d454b3d48624498efcce Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> (cherry picked from commit 5e68fe245fb97f38620ea683dbeab724bf86da4c) Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Suppress warning for trying to delete non-empty directoryThomas Wolf2018-09-111-0/+5
| | | | | | | | | | | | This is actually a fairly common occurrence; deleting the parent directories can work only if the file deleted was the last one in the directory. Bug: 537872 Change-Id: I86d1d45e1e2631332025ff24af8dfd46c9725711 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> (cherry picked from commit d9e767b431eae7978613cc8e0ade7467ec04376c) Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Prepare 4.7.4-SNAPSHOT buildsMatthias Sohn2018-09-0956-321/+321
| | | | | Change-Id: Ie4d17e1604270946606e75145012c5b7fa1283eb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.7.3.201809090215-rv4.7.3.201809090215-rMatthias Sohn2018-09-0956-59/+59
| | | | | Change-Id: I1ded7a2b61235509c5a6ba95e7329e288bbfddb1 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix atomic lock file creation on NFSMatthias Sohn2018-09-075-6/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FS_POSIX.createNewFile(File) failed to properly implement atomic file creation on NFS using the algorithm [1]: - name of the hard link must be unique to prevent that two processes using different NFS clients try to create the same link. This would render nlink useless to detect if there was a race. - the hard link must be retained for the lifetime of the file since we don't know when the state of the involved NFS clients will be synchronized. This depends on NFS configuration options. To fix these issues we need to change the signature of createNewFile which would break API. Hence deprecate the old method FS.createNewFile(File) and add a new method createNewFileAtomic(File). The new method returns a LockToken which needs to be retained by the caller (LockFile) until all involved NFS clients synchronized their state. Since we don't know when the NFS caches are synchronized we need to retain the token until the corresponding file is no longer needed. The LockToken must be closed after the LockFile using it has been committed or unlocked. On Posix, if core.supportsAtomicCreateNewFile = false this will delete the hard link which guarded the atomic creation of the file. When acquiring the lock fails ensure that the hard link is removed. [1] https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html also see file creation flag O_EXCL in http://man7.org/linux/man-pages/man2/open.2.html Change-Id: I84fcb16143a5f877e9b08c6ee0ff8fa4ea68a90d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use constant for ".lock"Matthias Sohn2018-09-077-13/+30
| | | | | | (cherry picked from commit 5f27032fb85694a093f827581216d4ffb99db68b) Change-Id: I6bc0e9a910b110418a82d8e574fb2aecc3a31d6a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix handling of option core.supportsAtomicCreateNewFileChristian Halstrick2018-09-071-4/+10
| | | | | | | | | | | | | When core.supportsAtomicCreateNewFile was set to false and the repository was located on a filesystem which doesn't support the file attribute "unix:nlink" then FS_POSIX#createNewFile may report an error even if everything was ok. Modify FS_POSIX#createNewFile to silently ignore this situation. An example of such a filesystem is sshfs where reading "unix:nlink" always returns 1 (instead of throwing a exception). Bug: 537969 Change-Id: I6deda7672fa7945efa8706ea1cd652272604ff19 Also-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GC: Avoid logging errors when deleting non-empty foldersHector Caballero2018-09-051-0/+3
| | | | | | | | | | | | | I88304d34c and Ia555bce00 modified the way errors are handled when trying to delete non-empty reference folders. Before, this error was silently ignored as it was considered an expected output. Now, every failed folder delete is logged which can be noisy. Ignore the DirectoryNotEmptyException but log any other error avoiding deletion of an eligible folder. Signed-off-by: Hector Oswaldo Caballero <hector.caballero@ericsson.com> Change-Id: I194512f67885231d62c03976ae683e5cc450ec7c
* Bazel: Use hyphen instead of underscore in external repository namesDavid Pursehouse2018-08-302-30/+30
| | | | | | | | | | | | | | Recent Bazel versions support the hyphen character in external repository names. On the Gerrit project, the repository names were harmonized to consistently use hyphen. As a side effect, it is no longer possible to build jgit from source in the gerrit tree, due to the different repository names. Rename the dependencies to use hyphens, consistent with gerrit. Change-Id: Ideebd858ddd3f0e6f765643001642dfb6c12441f Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Bazel: Format all build files with buildifier 0.15.0David Pursehouse2018-08-304-62/+61
| | | | | Change-Id: I8343b723da6e40d5ae7fc45c84f64c31276bd5dc Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* ChangeIdUtilTest: Remove unused notestCommitDashVDavid Pursehouse2018-08-301-17/+0
| | | | | | | | | | | | | | | | This test was never being run. Since it was introduced it was named "notest.." which meant it didn't run with JUnit3, and since it is not annotated @Test it also doesn't run with JUnit4. When compiling with Bazel 0.6.0, error-prone raises an error that the public method is not annotated with @Ignore or @Test. Given that the test has never been run anyway, we can just remove it. Bug: 525415 Change-Id: Ie9a54f89fe42e0c201f547ff54ff1d419ce37864 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Fix GC run in foreground to not use executorHugo Arès2018-08-152-55/+22
| | | | | | | | | | Since I3870cadb4, GC task was always delegated to an executor even when background option was set to false. This was an issue because if more than one GC object was instantiated and executed in parallel, only one GC was actually running because of the single thread executor. Change-Id: I8c587d22d63c1601b7d75914692644a385cd86d6 Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
* Prepare 4.7.3-SNAPSHOT buildsMatthias Sohn2018-07-2756-321/+321
| | | | | Change-Id: I5c437f45d5bc469e3c32bef1180c127d96d24d23 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.7.2.201807261330-rv4.7.2.201807261330-rMatthias Sohn2018-07-2656-59/+59
| | | | | Change-Id: I0d8c7ca756e6236e315c91da000fe8103ce83d05 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Delete all loose refs empty directoriesLuca Milanesio2018-07-264-21/+43
| | | | | | | | | | Remove completely the empty directories under refs/<namespace> including the first level partition of the changes, when they are completely empty. Bug: 536777 Change-Id: I88304d34cc42435919c2d1480258684d993dfdca Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use java.nio to delete path to get detailed errorsLuca Milanesio2018-07-261-5/+5
| | | | | | | | Get the full IOException of the reason why a directory cannot be removed during GC. Change-Id: Ia555bce009fa48087a73d677f1ce3b9c0b685b57 Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* GC: Remove empty references foldersHector Caballero2018-07-102-0/+164
| | | | | | | | | | | | | | | | | After packaging references, the folders containing these references are not deleted. In a busy repository, this causes operations to slow down as traversing the references tree becomes longer. Delete empty reference folders after the loose references have been packed. To avoid deleting a folder that was just created by another concurrent operation, only delete folders that were not modified in the last 30 seconds. Signed-off-by: Hector Oswaldo Caballero <hector.caballero@ericsson.com> Change-Id: Ie79447d6121271cf5e25171be377ea396c7028e0 Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Do not ignore path deletion errorsLuca Milanesio2018-07-081-2/+6
| | | | | | | | | Log as warning when an attempt to remove a directory fails. This helps troubleshooting some bugs like the GC leaving behind empty directories. Change-Id: Idb94ce17f8be9668a970c7ecae31436bf434073c Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
* ResolveMerger: Fix encoding with string; use bytesMarco Miller2018-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes the issue [1]. Before this fix, a merge involving the caching of consecutive yet similar filenames with Norwegian characters [2] used to throw an IllegalStateException: Duplicate stages not allowed. This was caused by inaccurate decoding of the filenames, using string values assuming default encoding. In the toString method of DirCacheEntry, used before through getPathString, UTF-8 encoding is used, but the end result becomes default encoding, through Object's default toString usage. The special characters in those two consecutive (particular) filenames [2] were becoming the very same decoded /single character, lending consecutive -but then identical- filenames. Thus the perceived duplicate 0-staging of the file(s). Replace getPathString usage with getRawPath for this specific case, or use byte array representations of cached entries instead of string. Adding a test for this change is not possible, as there is no known way to change the default encoding for filenames such as [2] (e.g.). JGitTestUtil does write file contents through UTF-8, but encoding like so does not apply to the actual file name. Hence there is no way to create files with names properly made of special characters such as [2]'s. And the test that is necessary for this case assumes such Norwegian (or similar characters) filenames. Changing the default locale programmatically in a test has no effect either. And changing the LANG value passed to the JVM is only possible upon starting it. [1] https://bugs.chromium.org/p/gerrit/issues/detail?id=9153 [2] <=> (...) "a/b/SíÒr-Norge.map", "a/b/Sør-Norge.map", (...) Change-Id: Ib9f2f5297932337c9817064cc09d9f774dd168f4 Signed-off-by: Marco Miller <marco.miller@ericsson.com>
* Merge branch 'stable-4.6' into stable-4.7David Pursehouse2018-06-201-0/+3
|\ | | | | | | | | | | | | | | * stable-4.6: Temporarily @Ignore flaky CommitCommandTest methods Change-Id: Idc653c22a9af2013a4c481bb19ca8d059f5c34d0 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| * Merge branch 'stable-4.5' into stable-4.6David Pursehouse2018-06-191-0/+3
| |\ | | | | | | | | | | | | | | | | | | | | | * stable-4.5: Temporarily @Ignore flaky CommitCommandTest methods Change-Id: I2a0e0b63a06f442f5a088d4bc8bb08eaf02ce952 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | * Temporarily @Ignore flaky CommitCommandTest methodsDave Borowitz2018-06-191-0/+3
| | | | | | | | | | | | | | | | | | Change-Id: Ia2c42d014323bd29b85bf76f1a20c83f612406d7 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> (cherry picked from commit e93b0026ced10c956e76daed038f2560a33b5baf)
* | | Merge branch 'stable-4.6' into stable-4.7Matthias Sohn2018-05-103-31/+56
|\| | | | | | | | | | | | | | | | | | | | * stable-4.6: Retry stale file handles on .git/config file Change-Id: If5a21d38224528edfc551b3216daca6a2582e3ac
| * | Merge branch 'stable-4.5' into stable-4.6Matthias Sohn2018-05-103-31/+56
| |\| | | | | | | | | | | | | | | | | | | * stable-4.5: Retry stale file handles on .git/config file Change-Id: Ib6e6ec0846c3ef261ec1016bfa6d26d2eadc3f26
| | * Retry stale file handles on .git/config fileNasser Grainawi2018-05-103-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 <nasser@codeaurora.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Merge branch 'stable-4.6' into stable-4.7Matthias Sohn2017-11-227-44/+158
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.6: Silence boxing warning Prepare 4.5.5-SNAPSHOT builds JGit v4.5.4.201711221230-r Fix LockFile semantics when running on NFS Honor trustFolderStats also when reading packed-refs Prepare 4.5.4-SNAPSHOT builds JGit v4.5.3.201708160445-r Change-Id: I8f6bc09540727c6273d22775a9f9ca382a729c9b Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | Silence boxing warningMatthias Sohn2017-11-221-0/+1
| | | | | | | | | | | | Change-Id: I36c40eb91ce0c51f89b47911fa14beffcbc0a7cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | Merge branch 'stable-4.5' into stable-4.6Matthias Sohn2017-11-228-40/+195
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.5: Prepare 4.5.5-SNAPSHOT builds JGit v4.5.4.201711221230-r Fix LockFile semantics when running on NFS Honor trustFolderStats also when reading packed-refs Prepare 4.5.4-SNAPSHOT builds JGit v4.5.3.201708160445-r Change-Id: Ie9c8e0d9172c8d53f075c284bf2a9677980d8dfb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Prepare 4.5.5-SNAPSHOT buildsMatthias Sohn2017-11-2256-302/+302
| | | | | | | | | | | | | | | Change-Id: I71f946f2875716670a2d74c21a8ab38a1f53a25c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * JGit v4.5.4.201711221230-rv4.5.4.201711221230-rMatthias Sohn2017-11-2256-59/+59
| | | | | | | | | | | | | | | Change-Id: Ia1079da239c5b3fde1ba8d2acc4e465a46297b4d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Fix LockFile semantics when running on NFSChristian Halstrick2017-11-225-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 https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html section III.d) "Exclusive File Creation" Change-Id: I3d2cc48d8eb280d5f7039eb94da37804f903be6a
| | * Honor trustFolderStats also when reading packed-refsChristian Halstrick2017-11-211-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
| | * Prepare 4.5.4-SNAPSHOT buildsMatthias Sohn2017-08-2656-302/+302
| | | | | | | | | | | | | | | Change-Id: Id8b902bf2bf590b41f2e246c5ecf1592e1c411f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * JGit v4.5.3.201708160445-rv4.5.3.201708160445-rMatthias Sohn2017-08-1656-59/+59
| | | | | | | | | | | | | | | Change-Id: I2d57144976e3683e180d3a42edc6c3bf2905e87c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Merge branch 'stable-4.6' into stable-4.7Matthias Sohn2017-08-149-13/+125
|\| | | | | | | | | | | | | | | | | | | | | | | * stable-4.6: Update Oxygen Orbit p2 repository to R20170516192513 Fix exception handling for opening bitmap index files Change-Id: I669fe48ce0034f9ea1977d38ee39099497422c1c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | Merge branch 'stable-4.5' into stable-4.6Matthias Sohn2017-08-142-2/+114
| |\| | | | | | | | | | | | | | | | | | | | | | * stable-4.5: Fix exception handling for opening bitmap index files Change-Id: Ifb511238e3e98b1bc9f79a990807b940a17ebaa6 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Fix exception handling for opening bitmap index filesChristian Halstrick2017-08-142-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 <matthias.sohn@sap.com>
| * | Update Oxygen Orbit p2 repository to R20170516192513Matthias Sohn2017-08-147-11/+11
| | | | | | | | | | | | Change-Id: I7f1b733ca414d77c9df5572df02e742e0a84ba2f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Prepare 4.7.2-SNAPSHOT buildsMatthias Sohn2017-06-0856-321/+321
| | | | | | | | | | | | | | | Change-Id: I7c127bd402cd84c68d8f33a32c6aad093a2264c8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | JGit v4.7.1.201706071930-rv4.7.1.201706071930-rMatthias Sohn2017-06-0856-59/+59
| | | | | | | | | | | | | | | Change-Id: I28cd8fbe995d76c8a00e7db6ddf826e983d89043 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 03:45:53 +0000