summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test
Commit message (Collapse)AuthorAgeFilesLines
* Prepare 4.5.5-SNAPSHOT buildsMatthias Sohn2017-11-222-42/+42
| | | | | Change-Id: I71f946f2875716670a2d74c21a8ab38a1f53a25c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.5.4.201711221230-rv4.5.4.201711221230-rMatthias Sohn2017-11-222-2/+2
| | | | | Change-Id: Ia1079da239c5b3fde1ba8d2acc4e465a46297b4d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Prepare 4.5.4-SNAPSHOT buildsMatthias Sohn2017-08-262-42/+42
| | | | | Change-Id: Id8b902bf2bf590b41f2e246c5ecf1592e1c411f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.5.3.201708160445-rv4.5.3.201708160445-rMatthias Sohn2017-08-162-2/+2
| | | | | Change-Id: I2d57144976e3683e180d3a42edc6c3bf2905e87c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix exception handling for opening bitmap index filesChristian Halstrick2017-08-141-0/+103
| | | | | | | | | | | | | | | | | | | | 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-082-42/+42
| | | | | Change-Id: I69681b7a5687ca76bd0dd5d3e7ce2cff841d0e32 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.5.2.201704071617-rv4.5.2.201704071617-rMatthias Sohn2017-04-072-2/+2
| | | | | Change-Id: I66402643d7c84c90bf5cefed4d2ec3aa68c94cfb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Prepare 4.5.2-SNAPSHOT buildsMatthias Sohn2017-03-252-42/+42
| | | | | Change-Id: I8485de1f3f63dc9ec445b8fb08093ca144aedc59 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v4.5.1.201703201650-rv4.5.1.201703201650-rMatthias Sohn2017-03-202-2/+2
| | | | | Change-Id: I88de7c9f52abbc4921a82208ed74d22aa19fb3cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix eviction of repositories with negative usage countHugo Arès2016-10-121-0/+21
| | | | | | | | | | 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>
* Merge "Fix carrying over flags during a RevWalk" into stable-4.5Shawn Pearce2016-09-241-0/+146
|\
| * Fix carrying over flags during a RevWalkChristian Halstrick2016-09-231-0/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Prepare 4.5.1-SNAPSHOT buildsMatthias Sohn2016-09-212-42/+42
| | | | | | | | | | Change-Id: I3305e8a09a3fb06f25a316cff2bdbb551d3ade68 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | JGit v4.5.0.201609210915-rv4.5.0.201609210915-rMatthias Sohn2016-09-212-2/+2
|/ | | | | Change-Id: Idc02a1a1d74f84605d764c239803f0cfbad94eb7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Handle all values of branch.[name].rebaseThomas Wolf2016-09-152-37/+58
| | | | | | | | | | | | | | | | | 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>
* Ignore trailing spaces in directory rule patternsAndrey Loskutov2016-09-143-1/+43
| | | | | | Bug: 500967 Change-Id: I7fabc2654af97011c62f46d5c30ee992341e45e2 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Add support for post-commit hooksMartin Goellnitz2016-09-131-0/+62
| | | | | Change-Id: I6691b454404dd4db3c690ecfc7515de765bc2ef7 Signed-off-by: Martin Goellnitz <m.goellnitz@outlook.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Don't log error if system git config does not existMatthias Sohn2016-09-051-0/+13
| | | | | | | | | | - enhance FS.readPipe to throw an exception if the external command fails to enable the caller to handle the command failure - reduce log level to warning if system git config does not exist - improve log message Bug: 476639 Change-Id: I94ae3caec22150dde81f1ea8e1e665df55290d42 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add missing dependency to slf4j-log4j bridgeMatthias Sohn2016-09-051-1/+2
| | | | | | Without the bridge JGit tests don't show log output in Eclipse console. Change-Id: I7acce1f1787960b5ca98377cb5c7f599a8a220b5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Rename FSJava7Test to FSTestMatthias Sohn2016-09-031-1/+1
| | | | | | | Since 4.0 JGit does no longer support Java versions older than Java 7 so there is no need anymore to mention Java 7 in the class name. Change-Id: Ic46c9d89a7e919ae4a69487fa06de0478d2b21f0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ReceivePack: refactor push option parsingShawn Pearce2016-08-261-10/+8
| | | | | | | | | | | | | Refactor all of the push option support code to allocate the list immediately before parsing the options section off the stream. Move option support down to ReceivePack instead of BaseReceivePack. Push options are specific to the ReceivePack protocol and are not likely to appear in the 4 year old subscription proposal. These changes are OK before JGit 4.5 ships as no consumer should be relying on these new APIs. Change-Id: Ib07d18c877628aba07da07cd91875f918d509c49
* Fix push option initalization on HTTPStefan Beller2016-08-261-1/+1
| | | | | | | | | | | Initialize pushOptions when we decide to use them, instead of when we advertise them. In the case of HTTP the advertisement is in a different network request, hence in a different instance of the BaseReceivePack. Change-Id: I094c60942e04de82cb6d8433c9cd43a46ffae332 Signed-off-by: Stefan Beller <sbeller@google.com>
* Clarify the semantics of DfsRefDatabase#compareAndPutMasaya Suzuki2016-08-251-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | DfsRefDatabase#compareAndPut had a vague semantics for reference matching. Because of this, an operation to make a symbolic reference had been broken for some DFS implementations even if they followed the contract of compareAndPut. The clarified semantics requires the implementations to satisfy the followings: * Matching references should be both symbolic references or both object ID references. * If both are symbolic references, both should have the same target name. * If both are object ID references, both should have the same object ID. This semantics is defined based on https://git.eclipse.org/r/#/c/77416/. Before this commit, DfsRefDatabase couldn't see the target of symbolic references. InMemoryRepository is changed to comply with the new semantics. This semantics change can affect the existing DFS implementations that only checks object IDs. This commit adds two tests that the previous InMemoryRepository couldn't pass. Change-Id: I6c6b5d3cc8241a81f4a37782381c88e8a59fdf15 Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
* NoteMapTest: Add missing @Test annotationsDave Borowitz2016-08-261-1/+7
| | | | | | | | | | The RepositoryTestCase hierarchy no longer comes from TestCase, so all test methods must have @Test. Fix one test that was broken but never run; fortunately this was just a typo in the test code. Change-Id: I3ac8ccdab5e2d5539c63d7b0a88d8bdb0c5ff66e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use FS#lastModified instead of File#lastModifiedMasaya Suzuki2016-08-243-15/+18
| | | | | | | | | | | | | | | This fixes the tests failed in JDK8. FS uses java.nio API to get file attributes. The timestamps obtained from that API are more precise than the ones from java.io.File#lastModified() since Java8. This difference accidentally makes JGit detect newly added files as smudged. Use the precised timestamp to avoid this false positive. Bug: 500058 Change-Id: I9e587583c85cb6efa7562ad6c5f26577869a2e7c Signed-off-by: Masaya Suzuki <masayasuzuki@google.com> Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Added Java 7 launch config with LANG env. variable setAndrey Loskutov2016-08-241-0/+30
| | | | | | | This avoids symlink test errors on Linux Change-Id: Id8193524c40394a90b8315ab0b8256670d618cb5 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Enhance ResetCommand to allow disabling reflog updateMatthias Sohn2016-08-171-0/+40
| | | | | | | This will be used by EGit for implementing commit amend in the staging view (see Idcd1efeeee8b3065bae36e285bfc0af24ab1e88f). Change-Id: Ice9ebbb1c0c3314c679f4db40cdd3664f61c27c3 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge "Add path src/ to source path in build.properties"Matthias Sohn2016-08-081-1/+2
|\
| * Add path src/ to source path in build.propertiesMatthias Sohn2016-08-061-1/+2
| | | | | | | | | | | | This fixes the warning "src/ is missing from source.." Change-Id: I166e3a6a3d5230e4110d3283ec4dbc7d1dfe6732 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Merge "Skip cleaning inner repositories by default in CleanCommand"Christian Halstrick2016-08-071-0/+40
|\ \
| * | Skip cleaning inner repositories by default in CleanCommandMatthaus Owens2016-08-041-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously jgit would attempt to clean git repositories that had not been committed by calling a non-recursive delete on them, which would fail as they are directories. This commit addresses that issue in the following ways. Repositories are skipped in a default clean, similarly to cgit and only cleaned when the force flag is applied. When the force flag is applied repositories are deleted using a recursive delete call. The force flag and setForce method are added here to CleanCommand to support this change. Bug: 498367 Change-Id: Ib6cfff65a033d0d0f76395060bf76719e13fc467 Signed-off-by: Matthaus Owens <matthaus@puppetlabs.com>
* | | Merge "Add testCleanDirsWithSubmodule test to CleanCommandTest"Christian Halstrick2016-08-071-0/+28
|\| | | |/ |/|
| * Add testCleanDirsWithSubmodule test to CleanCommandTestMatthaus Owens2016-08-041-0/+28
| | | | | | | | | | | | | | | | | | This commit adds some test coverage to cleaning a repository with a submodule, which did not previously exist. Bug: 498367 Change-Id: Ia5c4e4cc53488800dd486f8556dc57656783f1c4 Signed-off-by: Matthaus Owens <matthaus@puppetlabs.com>
* | Merge changes I27961679,I91be6165,If0dbd562Jonathan Nieder2016-08-051-3/+0
|\ \ | | | | | | | | | | | | | | | | | | * changes: LfsProtocolServlet: Allow access to objects in request LfsProtocolServlet: Allow getLargeFileRepository to raise exceptions Remove references to org.eclipse.jgit.java7
| * | Remove references to org.eclipse.jgit.java7David Pursehouse2016-08-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bundle org.eclipse.jgit.java7 was removed in 4.0. Remove references to it from the README.md. Remove reference to it from org.eclipse.jgit.test/.project, which causes an error message when opening the project in Eclipse: Resource '/org.eclipse.jgit.java7' does not exist. Change-Id: If0dbd562dcd60550bec3c0f793289474b7624bce Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | | Shallow fetch/clone: Make --depth mean the total history depthTerry Parker2016-08-051-7/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cgit changed the --depth parameter to mean the total depth of history rather than the depth of ancestors to be returned [1]. JGit still uses the latter meaning, so update it to match cgit. depth=0 still means a non-shallow clone. depth=1 now means only the wants rather than the wants and their direct parents. This is accomplished by changing the semantic meaning of "depth" in UploadPack and PackWriter to mean the total depth of history desired, while keeping "depth" in DepthWalk.{RevWalk,ObjectWalk} to mean the depth of traversal. Thus UploadPack and PackWriter always initialize their DepthWalks with "depth-1". [1] upload-pack: fix off-by-one depth calculation in shallow clone https://code.googlesource.com/git/+/682c7d2f1a2d1a5443777237450505738af2ff1a Change-Id: I87ed3c0f56c37e3491e367a41f5e555c4207ff44 Signed-off-by: Terry Parker <tparker@google.com>
* | | Shallow fetch: Respect "shallow" linesTerry Parker2016-08-051-22/+75
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When fetching from a shallow clone, the client sends "have" lines to tell the server about objects it already has and "shallow" lines to tell where its local history terminates. In some circumstances, the server fails to honor the shallow lines and fails to return objects that the client needs. UploadPack passes the "have" lines to PackWriter so PackWriter can omit them from the generated pack. UploadPack processes "shallow" lines by calling RevWalk.assumeShallow() with the set of shallow commits. RevWalk creates and caches RevCommits for these shallow commits, clearing out their parents. That way, walks correctly terminate at the shallow commits instead of assuming the client has history going back behind them. UploadPack converts its RevWalk to an ObjectWalk, maintaining the cached RevCommits, and passes it to PackWriter. Unfortunately, to support shallow fetches the PackWriter does the following: if (shallowPack && !(walk instanceof DepthWalk.ObjectWalk)) walk = new DepthWalk.ObjectWalk(reader, depth); That is, when the client sends a "deepen" line (fetch --depth=<n>) and the caller has not passed in a DepthWalk.ObjectWalk, PackWriter throws away the RevWalk that was passed in and makes a new one. The cleared parent lists prepared by RevWalk.assumeShallow() are lost. Fortunately UploadPack intends to pass in a DepthWalk.ObjectWalk. It tries to create it by calling toObjectWalkWithSameObjects() on a DepthWalk.RevWalk. But it doesn't work: because DepthWalk.RevWalk does not override the standard RevWalk#toObjectWalkWithSameObjects implementation, the result is a plain ObjectWalk instead of an instance of DepthWalk.ObjectWalk. The result is that the "shallow" information is thrown away and objects reachable from the shallow commits can be omitted from the pack sent when fetching with --depth from a shallow clone. Multiple factors collude to limit the circumstances under which this bug can be observed: 1. Commits with depth != 0 don't enter DepthGenerator's pending queue. That means a "have" cannot have any effect on DepthGenerator unless it is also a "want". 2. DepthGenerator#next() doesn't call carryFlagsImpl(), so the uninteresting flag is not propagated to ancestors there even if a "have" is also a "want". 3. JGit treats a depth of 1 as "1 past the wants". Because of (2), the only place the UNINTERESTING flag can leak to a shallow commit's parents is in the carryFlags() call from markUninteresting(). carryFlags() only traverses commits that have already been parsed: commits yet to be parsed are supposed to inherit correct flags from their parent in PendingGenerator#next (which doesn't happen here --- that is (2)). So the list of commits that have already been parsed becomes relevant. When we hit the markUninteresting() call, all "want"s, "have"s, and commits to be unshallowed have been parsed. carryFlags() only affects the parsed commits. If the "want" is a direct parent of a "have", then it carryFlags() marks it as uninteresting. If the "have" was also a "shallow", then its parent pointer should have been null and the "want" shouldn't have been marked, so we see the bug. If the "want" is a more distant ancestor then (2) keeps the uninteresting state from propagating to the "want" and we don't see the bug. If the "shallow" is not also a "have" then the shallow commit isn't parsed so (2) keeps the uninteresting state from propagating to the "want so we don't see the bug. Here is a reproduction case (time flowing left to right, arrows pointing to parents). "C" must be a commit that the client reports as a "have" during negotiation. That can only happen if the server reports it as an existing branch or tag in the first round of negotiation: A <-- B <-- C <-- D First do git clone --depth 1 <repo> which yields D as a "have" and C as a "shallow" commit. Then try git fetch --depth 1 <repo> B:refs/heads/B Negotiation sets up: have D, shallow C, have C, want B. But due to this bug B is marked as uninteresting and is not sent. Change-Id: I6e14b57b2f85e52d28cdcf356df647870f475440 Signed-off-by: Terry Parker <tparker@google.com>
* | Shallow fetch: avoid sending unneeded blobsTerry Parker2016-08-041-3/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing an incremental fetch from JGit, "have" commits are marked as "uninteresting". In a non-shallow fetch, when the RevWalk hits an "uninteresting" commit it marks the commit's corresponding tree as uninteresting. That has the effect of dropping those trees and all the trees and blobs they reference out of the thin pack returned to the client. However, shallow fetches use a DepthWalk to limit the RevWalk, which nearly always causes the RevWalk to terminate before encountering the "have" commits. As a result the pack created for the incremental fetch never encounters "uninteresting" tree objects and thus includes duplicate objects that it knows the client already has. Change-Id: I7b1f7c3b0d83e04d34cd2fa676f1ad4fec904c05 Signed-off-by: Terry Parker <tparker@google.com>
* | PackWriterTest: Improve readabilityTerry Parker2016-08-041-10/+17
|/ | | | | | | | Add wants() and haves() static utility functions to improve readability. Change-Id: I4d44e17a9af97c0203e2ebe112eabb1f67d272a6 Signed-off-by: Terry Parker <tparker@google.com>
* Annotate Sets#of with @SafeVarArgs to prevent heap pollution warningDavid Pursehouse2016-07-261-0/+1
| | | | | | | | | | | | | | | | This prevents the warning: Potential heap pollution via varargs parameter The method doesn't do any casting of types that would cause the heap pollution, so it should be safe to add @SafeVarArgs. See [1] for information about this warning. [1] http://stackoverflow.com/a/12462259/381622 Change-Id: Ic6d252915ea44b4f1c385afecb98906cd2c54382 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Ignore 'The value of exception parameter is not used' warningDavid Pursehouse2016-07-261-0/+1
| | | | | Change-Id: I50407e4a33e35b718ca40503fdd436f1f9f70fba Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Merge branch 'stable-4.4'David Pursehouse2016-07-261-0/+14
|\ | | | | | | | | | | | | | | | | * stable-4.4: JGit v4.4.1.201607150455-r RefDirectory: remove ref lock file for following ref dir removal Change-Id: Ifc8a782efd7f2f991e70ad2a3691a8dba66c7554 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
| * JGit v4.4.1.201607150455-rv4.4.1.201607150455-rMatthias Sohn2016-07-152-2/+2
| | | | | | | | | | Change-Id: I61dbc29a962c8185fb356fe1ca30a1e673166d47 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Merge "RefDirectory: remove ref lock file for following ref dir removal" ↵Christian Halstrick2016-07-151-0/+14
| |\ | | | | | | | | | into stable-4.4
| | * RefDirectory: remove ref lock file for following ref dir removalMarco Miller2016-06-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this fix, ref directory removal did not work. That was because the ref lock file was still in the leaf directory at deletion time. Hence no deep ref directories were ever deleted, which negatively impacted performance under large directory structure circumstances. This fix removes the ref lock file before attempting to delete the ref directory (which includes it). The other deep parent directories are therefore now successfully deleted in turn, since leaf's content (lock file) gets removed first. So, given a structure such as refs/any/directory[/**], this fix now deletes all empty directories up to -and including- 'directory'. The 'any' directory (e.g.) does not get deleted even if empty, as before. The ref lock file is still also removed in the calling block's finally clause, just in case, as before. Such double-unlock brought by this fix is harmless (a no-op). A new (private) RefDirectory#delete method is introduced to support this #pack-specific case; other RefDirectory#delete callers remain untouched. Change-Id: I47ba1eeb9bcf0cb93d2ed105d84fea2dac756a5a Signed-off-by: Marco Miller <marco.miller@ericsson.com>
* | | RefSpecs: allow construction of weird wildcarded RefSpecsStefan Beller2016-07-251-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gerrit's superproject subscription feature uses RefSpecs to formalize the ACLs of when the superproject subscription feature is allowed. As this is a slightly different use case than describing a local/remote pair of refs, we need to be more permissive. Specifically we want to allow: refs/heads/* refs/heads/*:refs/heads/master refs/heads/master:refs/heads/* Introduce a new constructor, that allows constructing these RefSpecs. Change-Id: I46c0bea9d876e61eb2c8d50f404b905792bc72b3 Signed-off-by: Stefan Beller <sbeller@google.com>
* | | RefSpec: reject refs ending in '/'Stefan Beller2016-07-251-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had a case in Gerrits superproject subscriptions where 'refs/heads/' was configured with the intention to mean 'refs/heads/*'. The first expression lacks the '*', which is why it is not considered a wildcard but it was considered valid and so was not found early to be a typo. Refs are not allowed to end with '/' anyway, so add a check for that. Change-Id: I3ffdd9002146382acafb4fbc310a64af4cc1b7a9 Signed-off-by: Stefan Beller <sbeller@google.com>
* | | Push implementation of option stringsDan Wang2016-07-221-0/+363
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example usage: $ ./jgit push \ --push-option "Reviewer=j.doe@example.org" \ --push-option "<arbitrary string>" \ origin HEAD:refs/for/master Stefan Beller has also made an equivalent change to CGit: http://thread.gmane.org/gmane.comp.version-control.git/299872 Change-Id: I6797e50681054dce3bd179e80b731aef5e200d77 Signed-off-by: Dan Wang <dwwang@google.com>
* | | Merge branch 'stable-4.4'Matthias Sohn2016-07-123-7/+198
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.4: Log if Repository.useCnt becomes negative Time based eviction strategy for repository cache Add method to read time unit from config Align include.path max depth with native git Config load should not fail on unsupported or nonexistent include path Allow using JDK 7 bootclasspath when compiling JGit using Java 8 Extract work queue to allow reusing it Change-Id: I6aeedb1cb8b0c3068af344a719c80a03ae68fc23 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * | Time based eviction strategy for repository cacheChristian Halstrick2016-07-122-4/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Repository.close() decrements the useCount to 0 currently the cache immediately evicts the repository from WindowCache and RepositoryCache. This leads to I/O overhead on busy repositories because pack files and references are inserted and deleted from the cache frequently. This commit defers the eviction of a repository from the caches until last use of the repository is older than time to live. The eviction is handled by a background task running periodically. Add two new configuration parameters: * core.repositoryCacheExpireAfter: cache entries are evicted if the cache entry wasn't accessed longer than this time in milliseconds * core.repositoryCacheCleanupDelay: defines the interval in milliseconds for running a background task evicting expired cache entries. If set to -1 the delay is set to min(repositoryCacheExpireAfter, 10 minutes). If set to 0 the time based eviction is switched off and no background task is started. If time based eviction is switched off the JVM can still evict cache entries if heap memory is running low. Change-Id: I4a0214ad8b4a193985dda6a0ade63b70bdb948d7 Also-by: Matthias Sohn <matthias.sohn@sap.com> Also-by: Hugo Arès <hugo.ares@ericsson.com> Also-by: Sasa Zivkov <sasa.zivkov@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-10 23:54:53 +0000