summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit
Commit message (Collapse)AuthorAgeFilesLines
* 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-093-45/+45
| | | | | Change-Id: Ie4d17e1604270946606e75145012c5b7fa1283eb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.7.3.201809090215-rv4.7.3.201809090215-rMatthias Sohn2018-09-093-4/+4
| | | | | 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-076-9/+25
| | | | | | (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
* 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-273-45/+45
| | | | | Change-Id: I5c437f45d5bc469e3c32bef1180c127d96d24d23 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.7.2.201807261330-rv4.7.2.201807261330-rMatthias Sohn2018-07-263-4/+4
| | | | | Change-Id: I0d8c7ca756e6236e315c91da000fe8103ce83d05 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Delete all loose refs empty directoriesLuca Milanesio2018-07-263-11/+19
| | | | | | | | | | 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-101-0/+46
| | | | | | | | | | | | | | | | | 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.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-226-33/+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-226-6/+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-223-43/+43
| | | | | | | | | | | | | | | Change-Id: I71f946f2875716670a2d74c21a8ab38a1f53a25c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * JGit v4.5.4.201711221230-rv4.5.4.201711221230-rMatthias Sohn2017-11-223-4/+4
| | | | | | | | | | | | | | | 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-263-43/+43
| | | | | | | | | | | | | | | Change-Id: Id8b902bf2bf590b41f2e246c5ecf1592e1c411f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * JGit v4.5.3.201708160445-rv4.5.3.201708160445-rMatthias Sohn2017-08-163-4/+4
| | | | | | | | | | | | | | | Change-Id: I2d57144976e3683e180d3a42edc6c3bf2905e87c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Merge branch 'stable-4.6' into stable-4.7Matthias Sohn2017-08-141-2/+11
|\| | | | | | | | | | | | | | | | | | | | | | | * 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-141-2/+11
| |\| | | | | | | | | | | | | | | | | | | | | | * 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-141-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Prepare 4.5.3-SNAPSHOT buildsMatthias Sohn2017-04-083-43/+43
| | | | | | | | | | | | | | | Change-Id: I69681b7a5687ca76bd0dd5d3e7ce2cff841d0e32 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * JGit v4.5.2.201704071617-rv4.5.2.201704071617-rMatthias Sohn2017-04-073-4/+4
| | | | | | | | | | | | | | | Change-Id: I66402643d7c84c90bf5cefed4d2ec3aa68c94cfb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Prepare 4.7.2-SNAPSHOT buildsMatthias Sohn2017-06-083-45/+45
| | | | | | | | | | | | | | | Change-Id: I7c127bd402cd84c68d8f33a32c6aad093a2264c8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | JGit v4.7.1.201706071930-rv4.7.1.201706071930-rMatthias Sohn2017-06-083-4/+4
| | | | | | | | | | | | | | | Change-Id: I28cd8fbe995d76c8a00e7db6ddf826e983d89043 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | ArchiveCommand: Create prefix entry with commit timeYasuhiro Takagi2017-06-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cgit archive command creates a prefix (root) directory entry in the archive file. That entry's time is set to the commit time. This patch makes jgit's behavior consistent with with cgit: prefix: hoge/ -> creates prefix directory "hoge/" entry. prefix: hoge//// -> creates prefix directory "hoge/" entry. prefix: hoge/foo -> does not create prefix directory entry, but for each file/directory entry, prefix is added. Change-Id: I2610e40ce37972c5f7456fdca6337e7fb07176e5 Signed-off-by: Yasuhiro Takagi <ytakagi@bea.hi-ho.ne.jp>
* | | Run auto GC in the backgroundDavid Turner2017-06-067-2/+312
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running an automatic GC on a FileRepository, when the caller passes a NullProgressMonitor, run the GC in a background thread. Use a thread pool of size 1 to limit the number of background threads spawned for background gc in the same application. In the next minor release we can make the thread pool configurable. In some cases, the auto GC limit is lower than the true number of unreachable loose objects, so auto GC will run after every (e.g) fetch operation. This leads to the appearance of poor fetch performance. Since these GCs will never make progress (until either the objects become referenced, or the two week timeout expires), blocking on them simply reduces throughput. In the event that an auto GC would make progress, it's still OK if it runs in the background. The progress will still happen. This matches the behavior of regular git. Git (and now jgit) uses the lock file for gc.log to prevent simultaneous runs of background gc. Further, it writes errors to gc.log, and won't run background gc if that file is present and recent. If gc.log is too old (according to the config gc.logexpiry), it will be ignored. Change-Id: I3870cadb4a0a6763feff252e6eaef99f4aa8d0df Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Cleanup and test trailing slash handling in ManifestParserHan-Wen Nienhuys2017-04-111-13/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a workaround for https://bugs.openjdk.java.net/browse/JDK-4666701. Change-Id: Idd04657e8d95a841d72230f8881b6b899daadbc2 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | ManifestParser: Throw exception if remote does not have fetch attributeHan-Wen Nienhuys2017-04-103-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the repo manifest documentation [1] the fetch attribute is marked as "#REQUIRED". If the fetch attribute is not specified, this would previously result in NullPointerException. Throw a SAXException instead. [1] https://gerrit.googlesource.com/git-repo/+/master/docs/manifest-format.txt Change-Id: Ib8ed8cee6074fe6bf8f9ac6fc7a1664a547d2d49 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | | Prepare 4.7.1-SNAPSHOTMatthias Sohn2017-04-063-45/+45
| | | | | | | | | | | | | | | Change-Id: I16a45035258276217446bccc0ad1b0991383aa0c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | JGit v4.7.0.201704051617-rv4.7.0.201704051617-rMatthias Sohn2017-04-053-4/+4
| | | | | | | | | | | | | | | Change-Id: Ic2bd6aca0b7a7e0597ffc1f7cf647b49878f9950 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Remove unused import from ManifestParserMatthias Sohn2017-03-311-1/+0
| | | | | | | | | | | | Change-Id: Ie60ef9c7bc6ce0fdf017949ebfb9a21753e70506 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Document the intended use of RepoCommand#setURI()Han-Wen Nienhuys2017-03-291-3/+8
| | | | | | | | | | | | | | | Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Change-Id: I4a59dd8278b7b0026094692127b7f55e89c10bae
* | | Noop changes to ManifestParserHan-Wen Nienhuys2017-03-291-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Parse the base URL in ManifestParser construction. This will signal errors earlier. * Simplify stripping of trailing slashes. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Change-Id: I4a86f68c9d7737f71cf20352cfe26288fbd2b463
* | | Consistently use 'path' for the path to a subrepo in RepoCommandHan-Wen Nienhuys2017-03-271-18/+18
| | | | | | | | | | | | | | | Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Change-Id: I79ea7eb7b4d319e0100e3121aca5ef82eb8ad92a
* | | Merge branch 'stable-4.6'Matthias Sohn2017-03-276-18/+268
|\| | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.6: Only mark packfile invalid if exception signals permanent problem Don't flag a packfile invalid if opening existing file failed Prepare 4.5.2-SNAPSHOT builds Change-Id: Ife4efad1135d3870a5a0fb71e60b9524fb8777ab Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | Merge branch 'stable-4.5' into stable-4.6David Pursehouse2017-03-276-18/+252
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.5: Only mark packfile invalid if exception signals permanent problem Don't flag a packfile invalid if opening existing file failed Prepare 4.5.2-SNAPSHOT builds Change-Id: I20b50981adc54c426666015ff04fe3bb1db9abd9 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | * Only mark packfile invalid if exception signals permanent problemMatthias Sohn2017-03-266-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 <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-15 06:26:35 +0000