summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* JGit v4.5.6.201903121547-rv4.5.6.201903121547-rMatthias Sohn2019-03-1256-59/+59
| | | | | Change-Id: I5a071ed10e1ac1ab28f992d45cde335c12556a80 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Check for packfile validity and fd before readingLuca Milanesio2019-03-121-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 <luca.milanesio@gmail.com>
* Move throw of PackInvalidException outside the catchLuca Milanesio2019-03-121-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 <luca.milanesio@gmail.com>
* Use FileSnapshot to get lastModified on PackFileLuca Milanesio2019-03-121-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 <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Include size when comparing FileSnapshotLuca Milanesio2019-03-125-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 <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Do not reuse packfiles when changed on filesystemLuca Milanesio2019-03-122-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 <luca.milanesio@gmail.com>
* Silence API warnings for new API introduced for fixesMatthias Sohn2019-03-121-0/+14
| | | | Change-Id: I3ea7ff2efd33ca6c780afaef9010cec82780d7fa Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Prepare 4.5.6-SNAPSHOT buildsMatthias Sohn2018-12-2456-302/+302
| | | | | Change-Id: I57c55187ada6d824b94a17f5a79a5bcff61f9ee9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.5.5.201812240535-rv4.5.5.201812240535-rMatthias Sohn2018-12-2456-59/+59
| | | | | Change-Id: I6e89e937c08757887967d91afb39cfbe8372d6b5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Call AdvertiseRefsHook before validating wantsMasaya Suzuki2018-12-241-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 <masayasuzuki@google.com> Signed-off-by: Jonathan Nieder <jrn@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge branch 'stable-4.4' into stable-4.5David Pursehouse2018-10-190-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 <david.pursehouse@gmail.com>
| * Merge branch 'stable-4.3' into stable-4.4stable-4.4David Pursehouse2018-10-190-0/+0
| |\ | | | | | | | | | | | | | | | | | | | | | * stable-4.3: JGit v4.0.3.201509231615-r Change-Id: I147d81a9cc9c0f9e66084897df9c88c369539db7 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | * Merge branch 'stable-4.2' into stable-4.3stable-4.3David Pursehouse2018-10-190-0/+0
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.2: JGit v4.0.3.201509231615-r Change-Id: Ic90ef74497afee9da4b49dcb53302b4efa5b9f26 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | | * Merge branch 'stable-4.1' into stable-4.2stable-4.2David Pursehouse2018-10-190-0/+0
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.1: JGit v4.0.3.201509231615-r Change-Id: I6cc5bcefad2e8dee3394770d36608f981bfc9a9e Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | | | * Merge branch 'stable-4.0' into stable-4.1stable-4.1David Pursehouse2018-10-190-0/+0
| | | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.0: JGit v4.0.3.201509231615-r Change-Id: Ie74b0392ef145ffd27dc903c45f7fec2d4492a17 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| | | | | * JGit v4.0.3.201509231615-rv4.0.3.201509231615-rstable-4.0Matthias Sohn2015-09-2346-49/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I7ec09e82d806cde61165a6ceb79de022f18d9fe2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | | | | Prepare 4.4.2-SNAPSHOT buildsMatthias Sohn2016-07-1556-302/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I1d75fb5bddb1a6dd23604ba57c9798c978afca89 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Replace Findbugs with Spotbugs in org.eclipse.jgit/pom.xmlDavid Pursehouse2018-10-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: If9cb0de7a0e7bd95eac7daeee140a18385192a48 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | | | | | Replace FindBugs with SpotBugsDavid Pursehouse2018-10-091-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] https://spotbugs.github.io/ [2] https://git.eclipse.org/r/#/c/101312/ Change-Id: Ib73d56b5980b55f4d7e09d87abec3138cac3d3dc 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)
* | | | | | 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>
* | | | | | 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>
* | | | | | 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>
* | | | | | Prepare 4.5.3-SNAPSHOT buildsMatthias Sohn2017-04-0856-302/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I69681b7a5687ca76bd0dd5d3e7ce2cff841d0e32 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | JGit v4.5.2.201704071617-rv4.5.2.201704071617-rMatthias Sohn2017-04-0756-59/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I66402643d7c84c90bf5cefed4d2ec3aa68c94cfb Signed-off-by: Matthias Sohn <matthias.sohn@sap.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>
* | | | | | Don't flag a packfile invalid if opening existing file failedLuca Milanesio2017-03-251-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 <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Prepare 4.5.2-SNAPSHOT buildsMatthias Sohn2017-03-2556-302/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I8485de1f3f63dc9ec445b8fb08093ca144aedc59 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | JGit v4.5.1.201703201650-rv4.5.1.201703201650-rMatthias Sohn2017-03-2056-59/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I88de7c9f52abbc4921a82208ed74d22aa19fb3cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Don't remove pack when FileNotFoundException is transientLuca Milanesio2017-03-153-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 <luca.milanesio@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Fix one case of missing objectHector Oswaldo Caballero2016-12-131-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 <hector.caballero@ericsson.com>
* | | | | | Use the same variable to check and extract LFS object idJacek Centkowski2016-11-241-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 <geminica.programs@gmail.com>
* | | | | | Config: do not add spaces before unitsDavid Turner2016-10-191-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 <dturner@twosigma.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | | | | | Unconditionally close repositories in RepositoryCache.clear()Matthias Sohn2016-10-131-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 <matthias.sohn@sap.com>
* | | | | | Fix eviction of repositories with negative usage countHugo Arès2016-10-122-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 <hugo.ares@ericsson.com>
* | | | | | pgm: Fix misspelled key of an externalized stringMatthias Sohn2016-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: 502107 Change-Id: I76d0981c8463b63bd049f50cdc7d549fa0604b3c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Add missing online help for Ketch server type option in CLI daemonMatthias Sohn2016-10-022-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I19d27bbdbfdb1c7a5a688e41dfcba73a142a1afd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Remove wrong junit dependencies in org.eclipse.jgit.pgmMatthias Sohn2016-10-021-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: 503010 Change-Id: I8fa99f53020af41eb15c1f63b6f3ba094d56bfef Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | Merge "Fix carrying over flags during a RevWalk" into stable-4.5Shawn Pearce2016-09-242-1/+147
|\ \ \ \ \ \
| * | | | | | Fix carrying over flags during a RevWalkChristian Halstrick2016-09-232-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
* | | | | | | Turn off doclint also during Maven site generationMatthias Sohn2016-09-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: Iefc77114de21e7a101642f5c3a8f0fb317886ba2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | | Prepare 4.5.1-SNAPSHOT buildsMatthias Sohn2016-09-2156-302/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I3305e8a09a3fb06f25a316cff2bdbb551d3ade68 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | | JGit v4.5.0.201609210915-rv4.5.0.201609210915-rMatthias Sohn2016-09-2156-59/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: Idc02a1a1d74f84605d764c239803f0cfbad94eb7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | | | | | Unconditionally close repository in unregisterAndCloseRepositorySaša Živkov2016-09-211-5/+3
|/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repository.close() method is used when reference counting and expiration needs to be honored. The RepositoryCache.unregisterAndCloseRepository method should close the repository unconditionally. This is also indicated from its javadoc. Change-Id: I19392d1eaa17f27ae44b55eea49dcff05a52f298
* | | | | | Handle all values of branch.[name].rebaseThomas Wolf2016-09-155-78/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BranchConfig treated this config property as a boolean, but git also allows the values "preserve" and "interactive". Config property pull.rebase also allows the same values. Replace private enum PullCommand.PullRebaseMode by new public enum BranchConfig.BranchRebaseMode and adapt all uses. Add a new setter to PullCommand. Note: PullCommand will treat "interactive" like "true", i.e., as a non-interactive rebase. Not sure how "interactive" should be handled. At least it won't balk on it. Bug: 499482 Change-Id: I7309360f5662b2c2efa1bd8ea6f112c63cf064af Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-05 09:21:32 +0000