aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test
Commit message (Collapse)AuthorAgeFilesLines
* Prepare for 2.1 maintenance changesstable-2.1Matthias Sohn2012-09-192-2/+2
| | | | Change-Id: I436f36a7c6dc86916eb4cde038b27f9fb183465a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v2.1.0.201209190230-rv2.1.0.201209190230-rMatthias Sohn2012-09-192-2/+2
| | | | | Change-Id: I9f94bce9a25644575a068c8fa459f74e06b02030 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Introduce "never" as parseable dateRobin Rosenberg2012-09-181-0/+11
| | | | | | | | | | For configuration parameter like "gc.pruneexpire" we need to understand the value "never". Never is handled as a date so far into the future that it will never happen. The actual value currently used is the constant GitDateParser.NEVER. Change-Id: I7744eaee9bf5026da517151c212c88325c348d6c Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* Introduce ParseExceptions for GitDateParserChristian Halstrick2012-09-172-24/+100
| | | | | | | | | Instead of just returning null when something was not parseable we should throw a real ParseException. This allows us to distinguish between specifications which are unparseable and those which represent no date (e.g. "never") Change-Id: Ib3c1aa64b65ed0e0270791a365f2fa72ab78a3f4
* Additional unit tests for the GCSasa Zivkov2012-09-161-1/+363
| | | | | Change-Id: Id5b578f7040c6c896ab9386a6b5ed62b0f495ed5 Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* cleanup: use assertArrayEquals for assertion on arraysRobin Rosenberg2012-09-0310-45/+43
| | | | Change-Id: I1df945011f8e5f03959b693d3564fe357e707f91
* cleanup: Prefer assertEquals over assertTrue(....equals(...))Robin Rosenberg2012-09-0313-44/+43
| | | | | | That is the common style and yields better diagnostics on failure. Change-Id: I831a55615a812734af0912a5d6bbfd1edc75308e
* Merge "Support branches with name 'config'"Christian Halstrick2012-09-031-0/+13
|\
| * Support branches with name 'config'Christian Halstrick2012-08-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JGit was not able to lookup refs which had the name of files which exist in the .git folder. When JGit was looking up a ref named X it has a fixed set of directories where it searched for files named X (ignore packed refs for now). First directory to search for is .git. In case of the ref named 'config' it searched there for this file, found it (it's the .git/config file with the repo configuration in it), parsed it, found it is an invalid ref and stopped searching. It never looked for a file .git/refs/heads/config. I changed JGit in a way that when it finds a file in GIT_DIR which corresponds to a ref name and if this file doesn't contain a valid ref then it will ignore the InvalidObjectIdException and continue searching. Change-Id: Ic26a329fb1624a5b2b2494c78bac4bd76817c100 Bug: 381574 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Stefan Lay <stefan.lay@sap.com>
* | Merge "Add tests for more coverage of CheckoutCommand"Matthias Sohn2012-09-031-0/+65
|\ \
| * | Add tests for more coverage of CheckoutCommandRobin Stocker2012-09-031-0/+65
| | | | | | | | | | | | | | | Change-Id: Id3ab5f56f88d7e9636c71b30258c268a75fc422e Signed-off-by: Robin Stocker <robin@nibor.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | DirCacheCheckout: Fix handling of files not in indexRobin Stocker2012-09-012-9/+38
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a file is not in the index and neither contents nor mode differ between "head" and "merge", the index state should be kept. If they differ, a checkout conflict should occur. This is described in Git's git-read-tree.txt. JGit used to replace the index state with "merge" in both of the above cases. A confusing effect of this was that when one removed a file and then did a rebase, the file silently reappeared again. The changes to dir/file conflict handling are a consequence of this change, as the index handling change made tests in DirCacheCheckoutTest break. I compared these cases to C Git and the new behavior there also matches what C Git does. Bug: 387390 Change-Id: I5beb781f12172a68f98c67d4c8029eb51ceae62d Signed-off-by: Robin Stocker <robin@nibor.org>
* | Create an input stream that transforms LF to CRLFRobin Rosenberg2012-09-011-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | The transformation is the same as AutoCRLFOutputStream does, but the direction is reversed. The tests are reused, but the implementation derives somewhat from the EolCanonicalizingInputStream. This stream will be used to compare blobs with LF line endings with worktree data that has CRLF line endings. Bug: 387501 Change-Id: I80d96e453e7f780dd464a89778de124cf35384e1 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Implement a parser for datesChristian Halstrick2012-08-281-0/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to parse user specified strings containing date and time info a thread-safe parser is implemented. This is needed for example to interpret configuration parameters (e.g. gc.pruneexpire where need to parse strings like "2 weeks ago"). The parser is thread-safe by caching SimpleDateFormat instances in a ThreadLocal cache. Native git has a parser called approxidate which is able to interpret a huge number of formats ("1 year ago", "tea time", ...). Ideally JGit should be able to parse the same strings as native git but for now this parser understands the following subset: "now" "yesterday" "(x) years|months|weeks|days|hours|minutes|seconds ago" "yyyy-MM-dd HH:mm:ss Z" (ISO) "EEE, dd MMM yyyy HH:mm:ss Z" (RFC) "yyyy-MM-dd" "yyyy.MM.dd" "MM/dd/yyyy" "dd.MM.yyyy" "EEE MMM dd HH:mm:ss yyyy Z" (DEFAULT) "EEE MMM dd HH:mm:ss yyyy" (LOCAL) Change-Id: Iccb66dadb60da13104e73140e53d5e2de068369c
* | Merge changes I98df46ce,Ifb815a12,I051a1724Robin Rosenberg2012-08-212-5/+91
|\ \ | | | | | | | | | | | | | | | | | | * changes: Support [<ref>]@{upstream} revision syntax Support parsing previous checkout as a revision expresion. Allow a @ without branch in revision syntax
| * | Support [<ref>]@{upstream} revision syntaxRobin Rosenberg2012-07-201-0/+23
| | | | | | | | | | | | | | | | | | | | | Resolves into a ref name corresponding to the named (or current) branch's upstream ref. Change-Id: I98df46cedb498724cf14343fbb168f24ff667929
| * | Support parsing previous checkout as a revision expresion.Robin Rosenberg2012-07-202-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repository.resolve can only return an ObjectId and will continue to do so, but another method, simplify(), will be able to return a branch name for some cases. Previous checkouts can be specified as @{-n}, where n is an integer speifying the n:th previous branch. The result is the branch name, unless the checkout was a detached head, in which case the object id is returned. Since the result is a branch it may be followed by a references to the reflog, such as @{-1}@{1} if necessary. A simple expression like "master" is resolved to master in simplify, but anything starting with refs gets resolved to its object id, even if it is a branch. A symbolic ref is resolved to its leaf ref, e.g. "HEAD" might be resolved to "master". Change-Id: Ifb815a1247ba2a3e2d9c46249c09be9d47f2b693
| * | Allow a @ without branch in revision syntaxRobin Rosenberg2012-07-161-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | No branch before @ is interpreted as the currently checked out branch. For detached heads it would be HEAD, but normally it is the branch that HEAD refers to. Change-Id: I051a1724fa390b8212e8986ba832b1347a20371e
* | | Merge changes I4f73487b,I1d1ed122Matthias Sohn2012-08-212-1/+3
|\ \ \ | |_|/ |/| | | | | | | | | | | * changes: The Git API's only likes /, not \ in paths Skip a test that cannot be verified on Windows
| * | The Git API's only likes /, not \ in pathsRobin Rosenberg2012-08-211-1/+1
| | | | | | | | | | | | | | | | | | Therefore this test fails on Windows Change-Id: I4f73487b720ea1479e95108344f1dc3711106408
| * | Skip a test that cannot be verified on WindowsRobin Rosenberg2012-08-211-0/+2
| | | | | | | | | | | | Change-Id: I1d1ed122c714f39ca7fb557224756205274804eb
* | | Teach BranchTrackingStatus to handle tracking of local branchesMatthias Sohn2012-08-181-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | EGit wasn't able to decorate local branches tracking another local branch with number of commits the checked out local branch differs from the other local branch it's tracking. Bug: 376970 Change-Id: I74e932d5eacd74dbf6b0dffcfc65ba3222a8250e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Improve ours/theirs conflict markers for rebase, cherry-pickRobin Stocker2012-08-183-5/+44
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On conflicts in rebase or cherry-pick, the conflict markers were like this: <<<<<<< OURS a ======= b >>>>>>> THEIRS This is technically correct, but it could be better. It's especially confusing during a rebase, where the meaning of OURS/THEIRS is not obvious. The intuition is that "ours" is the commits that "I" did before the rebase, but it's the other way around because of the way rebase works. See various bug reports and stackoverflow discussions. With this change, in the case of a cherry-pick while on master, the markers will be like this: <<<<<<< master a ======= b >>>>>>> bad1dea Message of the commit I'm cherry-picking In the case of a "git rebase master": <<<<<<< Upstream, based on master a ======= b >>>>>>> b161dea Message of a commit I'm rebasing It's not "master" because that would only be correct for the first cherry-pick during a rebase, after that, it's master + already cherry-picked commits. And in the case of a "git pull --rebase": <<<<<<< Upstream, based on branch 'master' of git@example.org:repo a ======= b >>>>>>> b161dea Message of a commit I'm rebasing Bug: 336819 Change-Id: I1333a8dd170bb0077f491962013485efb6f2a926 Signed-off-by: Robin Stocker <robin@nibor.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Fix idOffset when the working tree iterator matches a dircache entryRobin Rosenberg2012-08-151-0/+25
| | | | | | | | | | | | idOffset is not zero when idBuffer comes from blob in the dircache Change-Id: Iff768422cba140a5d6a776e2c627b852f079c1da
* | Merge "Allow JGit to read C Git rebase state"Christian Halstrick2012-08-131-2/+2
|\ \
| * | Allow JGit to read C Git rebase stateRobin Rosenberg2012-08-071-2/+2
| | | | | | | | | | | | | | | | | | C Git prefixes the time stamp in the author script with a "@" Change-Id: I140b29519acc101da78296eef562368fc6b61135
* | | Allow detection of case insensitive file systemsMatthias Sohn2012-08-062-0/+20
| | | | | | | | | | | | | | | | | | Change-Id: I03f59d07bcc3338ef8d392cbd940799186ca03bd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
* | | Ensure a directory exists before trying to create/merge a file into it.Jevgeni Zelenkov2012-08-062-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since git doesn't keep track of empty directories, they should be created first. Test case included demonstrates that using StashApplyCommand(). Bugfix is applied to the DirCacheCheckout class, because StashApplyCommand() uses it internally to apply a stash. Change-Id: Iac259229ef919f9e92e7e51a671d877172bb88a8 Signed-off-by: Jevgeni Zelenkov <jevgeni.zelenkov@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Merge "Fix PlotCommit for commits with duplicate parents"Robin Rosenberg2012-08-051-0/+34
|\ \ \ | |/ / |/| |
| * | Fix PlotCommit for commits with duplicate parentsRobin Rosenberg2012-08-051-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JGit allows to create commits which have duplicate parents: e.g. a commit X has first parent Y and second parent Y. Such commits are not handled correctly by PlotCommit leading to wrong display of the history in EGit. In such cases there is a never ending passing line drawn beside all commits younger than the commit with duplicate parents. This commit fixes this by explicitly checking for duplicate parents. In a different commit we should fix JGit not to create commits with duplicate parents. I think native git also doesn't allow such commits, although history display in native git (gitk, git log --graph) is not damaged by such commits. Change-Id: Ie3019ef613a507023958bea27b1badc3b8950279
* | | Merge "Fix resolving of relative file URIs in TransportLocal"Robin Rosenberg2012-07-291-0/+13
|\ \ \
| * | | Fix resolving of relative file URIs in TransportLocalRobin Stocker2012-07-271-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A configured remote url like "../repo" works with C Git. In JGit, it only worked if Java's current working directory happened to be the local repository working directory. Change-Id: I33ba3f81b37d03cf17ca7ae25a90774a27e7e02b Signed-off-by: Robin Stocker <robin@nibor.org>
* | | | Merge "Garbage collector for FileRepositories"Robin Rosenberg2012-07-292-2/+401
|\ \ \ \ | |/ / / |/| | |
| * | | Garbage collector for FileRepositoriesChristian Halstrick2012-07-292-2/+401
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements a garbage collector for FileRepositories. Main ideas are copied from the garbage collector for DFS based repos (DfsGarbageCollector). Added functionalities are - pruning loose objects - handling of the index - packing refs - handling of reflogs (objects referenced from reflog will not be pruned/) These are features of a GC which are not handled in this change and which should come with subsequent changes: - unpacking packed objects into loose objects (to support that pruning packed objects doesn't delete them until they are older than two weeks) - expiration of reflogs - support for configuration parameters (e.g. gc.pruneExpire) Change-Id: I14ea5cb7e0fd1b5c50b994fd77f4e05bfbb9d911 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
* | | | Again teach ResolveMerger to create more correct DirCacheEntry'sChristian Halstrick2012-07-262-0/+468
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, after a merge/cherry-pick/rebase, all index entries are smudged as the ResolveMerger never sets entry lengths and/or modification times. This change teaches it to re-set them at least for things it did not touch. The other entries are then repaired when the index is persisted, or entries are checked out. The first attempt to get this in was commit 3ea694c2523d909190b5350e13254a62e94ec5d5 which has been reverted. Since then some fixes to ResolveMerger and a few more tests have been added which check situations where the index is not matching HEAD before we merge. Change-Id: I648fda30846615b3bf688c34274c6cf4bc857832 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Also-by: Markus Duft <markus.duft@salomon.at>
* | | | Revert "Teach ResolveMerger to create more correct DirCacheEntry's"Shawn Pearce2012-07-242-206/+1
|/ / / | | | | | | | | | | | | | | | This reverts commit 3ea694c2523d909190b5350e13254a62e94ec5d5 Merges with unmodified subtrees are broken with this commit present. Back it out until a fixed version can be supplied.
* | | Teach ResolveMerger to create more correct DirCacheEntry'sMarkus Duft2012-07-192-1/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, after a merge/cherry-pick/rebase, all index entries are smudged as the ResolveMerger never sets entry lengths and/or modification times. This change teaches it to re-set them at least for things it did not touch. The other entries are then repaired when the index is persisted, or entries are checked out. Change-Id: I0944f2017483d32043d0d09409b13055b5609a4b Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
* | | Make ApplyCommand create missing parent directories for new filesMarkus Duft2012-07-162-0/+17
| |/ |/| | | | | | | | | | | | | | | | | Otherwise applying will fail with a FileNotFoundException, because File.createNewFile() fails with missing parents. Contains change & according test. Change-Id: I970522b549b8bb260ca6720da11f12c57ee8a492 Signed-off-by: Chris Aniszczyk <zx@twitter.com>
* | Create parent dir if necessary on checkoutRobin Stocker2012-07-081-0/+15
|/ | | | | | | | | An example where this is necessary is when a whole directory was deleted and checkout is used to restore a file which was in that directory. Bug: 372133 Change-Id: I1d45e0a5d2525fe1fdfbf08c9c5c166dd909e9fd Signed-off-by: Robin Stocker <robin@nibor.org>
* Use the working tree's .gitmodules in SubmoduleWalk.forIndex()Dave Borowitz2012-06-251-3/+3
| | | | | | | This was broken in fe1f1b8f8aba60fdd1ad6f0f72e9c9180978cc60, which preferred the index over the working tree when both were present. Change-Id: I97dcf9a088adcbd0187fa7eec9ef34445ce3a981 Signed-off-by: Kevin Sawicki <kevin@github.com>
* Merge changes I6b2ce96b,I499f518fChristian Halstrick2012-06-252-0/+143
|\ | | | | | | | | | | * changes: Fix order of deletion for files/dirs in ResolveMerger Don't return success on failing paths in ResolveMerger
| * Fix order of deletion for files/dirs in ResolveMergerRobin Stocker2012-06-231-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, the paths to delete were stored in a HashMap, which doesn't have a particular order. So when e.g. both the file "a/b" and the directory "a" were to be deleted, it would sometimes try to delete "a" first. This resulted in a failed path because File#delete() fails when a directory isn't empty. With this change, an ArrayList is used for storing the paths to delete. The list contains the paths in a top-down order, as defined by the order of processEntry. When the files are deleted, the list is iterated in reverse, ensuring that all files of a directory are deleted before the directory itself. Bug: 354099 Change-Id: I6b2ce96b3932ca84ecdfbeab457ce823c95433fb Signed-off-by: Robin Stocker <robin@nibor.org>
| * Don't return success on failing paths in ResolveMergerRobin Stocker2012-06-231-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ResolveMerger#mergeImpl() was only returning false (= failed) when there were unmerged paths. In the case when there were only failing paths, it returned true. Because MergeCommand looks at the return value for determining if the merge failed, it would fall into the successful case there, where it should instead return a MergeResult with MergeStatus.FAILED. This change adds a test case for this and makes the ResolveMerger return false when there are failing paths. This was discovered while working on fixing bug 354099 and is needed for its test case. Bug: 354099 Change-Id: I499f518f6289ef93e017db924b2aa857f2154707 Signed-off-by: Robin Stocker <robin@nibor.org>
* | Ignore empty lines when parsing git-rebase-todoRobin Stocker2012-06-231-2/+25
|/ | | | | | | | | | | | | | | | When starting a rebase with C Git, there may be empty lines in the git-rebase-todo file. Before this change, JGit would fail to parse the file with e.g. the following exception: JGitInternalException: Unknown or unsupported command " #", only "pick" is allowed. This happened when there was an empty line just before the comments, because the nextSpace would be the one from the comment. Now the empty lines are ignored by checking for nextSpace < ptr outside of the loop. Change-Id: I94ad299f367c846e7729c74f49c6b8f93f75ae81 Signed-off-by: Robin Stocker <robin@nibor.org>
* Merge "Fix boxing warnings in org.eclipse.jgit.lib.ConfigTest"Shawn Pearce2012-06-181-4/+4
|\
| * Fix boxing warnings in org.eclipse.jgit.lib.ConfigTestTomasz Zarna2012-06-181-4/+4
| | | | | | | | Change-Id: Ie6ae7ade36a117c22c656f792266d4116d52b9bc
* | Merge "ReceivePack supports InputStream data after pack"Shawn Pearce2012-06-161-0/+148
|\ \
| * | ReceivePack supports InputStream data after packIan Wetherbee2012-06-151-0/+148
| | | | | | | | | | | | | | | | | | | | | When receiving a pack, data buffered after the pack can restored to the InputStream if the stream supports mark and reset. Change-Id: If04915c32c91be28db8df7e8491ed3e9fe0e1608
* | | Fix resource leaks due to unclosed repositoriesChristian Halstrick2012-06-167-21/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever a call to JGit returns a Repository the caller should make sure to call close() on it if he doesn't need it anymore. Since instances of Repository contain e.g. open FileOutputStreams (for pack files) forgetting to close the repository can lead to resource leaks. This was the reason why dozens of the JUnit tests failed on Windows with "Can't delete file ...." errors. In LocalDiskRepositoryTestCase.tearDown() we tried to delete the repositories we used during tests which failed because we had open FileOutputStreams. Not only the obvious cases during Clone or Init operations returned Repositories, but also the new SubModule API created repository instances. In some places we even forgot to close submodule repositories in our internal coding. To see the effects of this fix run the JGit JUnit tests under Windows. On other platforms it's harder to see because either the leaking resources don't lead to failing JUnit tests (on Unix you can delete files with open FileOutputStreams) or the java gc runs differently and cleans up the resources earlier. Change-Id: I6d4f637b0d4af20ff4d501db091548696373a58a Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Fix LockFileTest on WindowsChristian Halstrick2012-06-161-2/+3
|/ / | | | | | | | | | | | | | | | | | | LockFileTest was failing on Windows because we couldn't delete the lock file of the index. The reason was that a LockFile instance still had an open handle to the lock file preventing us to delete the file (in contrast to the behavior on other platforms). Change-Id: I1d50442b7eb8a27f98f69ad77c5e24a9698a7b66 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-14 02:03:04 +0000