summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.java7.test/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge bundle org.eclipse.jgit.java7 into org.eclipse.jgitMatthias Sohn2015-03-237-1173/+0
| | | | | | | As we moved minimum Java version to 7 we don't need a separate bundle and feature for JGit features depending on Java 7 anymore. Change-Id: Ib5da61b0886ddbdea65298f1e8c6d65c9879ced1 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Support for the commit-msg hook.Laurent Delaigue2015-03-021-0/+58
| | | | | | | | This hook uses the file .git/COMMIT_EDITMSG to receive and potentially modify the commit message. Change-Id: Ibe2faadfb5d3932a5a3da2252d8156c4c04856c7 Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Refactored pre-commit hook to make it less invasive.Laurent Delaigue2015-03-021-17/+15
| | | | | | | | | Hooks are now obtained via a convenient API like git commands, and callers don't have to check for their existence. The pre-commit hook has been updated accordingly. Change-Id: I3383ffb10e2f3b588d7367b9139b606ec7f62758 Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Support for the pre-commit hookLaurent Goubet2015-02-021-0/+30
| | | | | | | | | Introduce support for the pre-commit hook into JGit, along with the --no-verify commit command option to bypass it when rebasing / cherry-picking. Change-Id: If86df98577fa56c5c03d783579c895a38bee9d18 Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add a hook testMatthias Sohn2015-02-021-0/+106
| | | | Change-Id: I8059ef299aeb43373f4f45274030886171a20a8e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Set permission bits for "executable" attribute according to the umaskAndrey Loskutov2014-11-221-2/+76
| | | | | | Bug: 424395 Change-Id: I3f5c55dd4c084529af2319029305ba2e174e0636 Signed-off-by: Andrey Loskutov <loskutov@gmx.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge "Remove redundant semicolon"Robin Rosenberg2014-08-101-1/+0
|\
| * Remove redundant semicolonRobin Rosenberg2014-08-101-1/+0
| | | | | | | | Change-Id: I15370d7807c82ee85ed7fdb05061a4baf0a77a68
* | Replace deprecated method call in Java7 FTI testRobin Rosenberg2014-08-101-1/+2
|/ | | | Change-Id: I3bbb6da951765d79d77aa955edeac7b5e4da5d8a
* Fix reading past FileTreeIterator EOF in FileTreeIteratorJava7TestRoberto Tyley2014-05-211-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stepping past the '.git' entry with `fti.next(1)` is unnecessary and in fact a bug, as the subsequent access to FileTreeIterator is past it's end-of-file - it has only 1 valid entry ('link'). This bug is only visibly exposed in certain environments depending on the (unguaranteed) return order of `java.io.File.listFiles()`. On my box FileTreeIteratorJava7Test would fail consistently for these 3 tests: * testSymlinkActuallyModified * testSymlinkNotModifiedThoughNormalized * testSymlinkModifiedNotNormalized They all failed in the same way: testSymlinkActuallyModified(org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test) Time elapsed: 0.063 sec <<< ERROR! org.eclipse.jgit.api.errors.JGitInternalException: /home/roberto/development/jgit/org.eclipse.jgit.java7.test/target/jgit_test_9202429389985749040_tmp /tmp_807992722429349842/.git (Is a directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:146) at org.eclipse.jgit.treewalk.FileTreeIterator$FileEntry.openInputStream(FileTreeIterator.java:210) at org.eclipse.jgit.treewalk.WorkingTreeIterator.readContentAsNormalizedString(WorkingTreeIterator.java:984) at org.eclipse.jgit.treewalk.WorkingTreeIterator.contentCheck(WorkingTreeIterator.java:924) at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:860) at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:815) at org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test.testSymlinkActuallyModified(FileTreeIteratorJava7Test.java:198) Theses tests are all working with a small repo that has just two entries: '.git' and 'link' (a symbolic link that's being tested on). `listFiles()` is called by FileTreeIterator to get a preliminary list of FileEntry objects: https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java#L139 Whether your tests appeared to pass or fail was dependent on the returned order of files from `listFiles()`: * ['.git', 'link'] - PASS (Eclipse Hudson appears to get this ordering) * ['link', '.git'] - FAIL (My env, Ubuntu 14.04/Java 1.7.0_55) The tree-iterator passes the resulting `FileEntry`s to it's init() method: https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java#L639-L665 ... where a count of valid entries is made (`entryCnt`), the 'invalid' entries (like'.git') being left in the hinterland of the `entries` array. The rearrangement in the entries array for our tests looks like this: * ['.git', 'link'] -> ['link', 'link'] * ['link', '.git'] -> ['link', '.git'] In both cases, `entryCnt` is set to 1, meaning that the _valid_ portion of the iterator is the same (ie ['link']), but that the portion after EOF, which we reach by calling `fti.next(1)`, is _different_ depending on your environment. The entry used by the iterator at that point will be either 'link' (if you're lucky) or '.git', which will blow up the test. Note that somewhat ironically, the 'self-check' assertions don't catch this bug, as 'path' data is only parsed _before_ EOF - so `fti.getEntryPathString()` returns the string "link" (and the assertion passes) regardless of whether you're about to read the '.git' entry or not. Change-Id: Ie58a7bc76b740ee52881ebf555564a74379028d6 Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
* Merge branch 'stable-3.3'Matthias Sohn2014-03-051-2/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-3.3: Update scripts to deploy jgit on Maven central Prepare 3.3.1-SNAPSHOT builds JGit v3.3.0.201403021825-r Fix merge/cherry-picking in CRLF mode Expose the received pack size in ReceivePack Revert "Add getPackFile to ReceivePack to make PostReceiveHook more usable" Avoid an NPE after 7b01a5369210 Add a launcher for Java 7 tests Remove obsolete getRepositoryMethod from WorkingTreeIterator Fix NPE when WorkingTreeIterator does not have a repository set Add getPackFile to ReceivePack to make PostReceiveHook more usable Possibility to limit the max pack size on receive-pack Package httpclient and httpcore in o.e.j.http.apache.feature Change-Id: I814a150980854bbaabd767f97b062d247af6cb50 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Fix NPE when WorkingTreeIterator does not have a repository setRobin Rosenberg2014-02-281-2/+4
| | | | | | | | | | | | | | It's strange that we have that member since it is not so clear when it it set or not. Change-Id: I53903a264f46866d249901a3cd9f9295028aa6bd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Windows: Test that we can create a symlink before the target is createdRobin Rosenberg2014-02-121-0/+74
|/ | | | | | | | | | | | According to Win32 API, you need to specificy whether a symlink points to a file or directory. These tests suggests a symlink created for a file, can actually point to a directory. We can also create the link before the target exists, so at least in this respect Windows symbolic links appears to work as POSIX links. On POSIX systems these tests have no relevance. Change-Id: Id3991a4fc4333087c6f569acf04f503b0a0f170d
* Add some tests cases on files modes for symbolic linksAxel Richard2014-02-121-0/+263
| | | | | | | | | Test that the file mode of a file is the one expected before and after a checkout. Tests between symlink and file, symlink and folder, symlink and missing. Change-Id: If65a85a5667e25103eb9fd328a8723e29de04a1f Signed-off-by: Axel Richard <axel.richard@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add some test cases for symbolic links with Java7Robin Rosenberg2014-02-122-0/+271
| | | | Change-Id: Ia4c9c7902316bc0a90fb89d8dea9902835c06dfa
* FileUtils.delete does not recurse via symlinksRobin Rosenberg2014-02-121-0/+86
| | | | Change-Id: I134cfbda47f4d252fec1a16034e2e78b73cd5081
* Length of symbolic link is the number of bytes, not charactersRobin Rosenberg2014-02-101-5/+5
| | | | Change-Id: I6b615f0d5da4339f1f23a29bcaeb80f0346f5764
* Remove hardcoded target/trash from test casesShawn Pearce2013-11-011-4/+4
| | | | | | | | | | | Buck does not create a target directory for the build output, this is Maven specific and the project unit tests should not rely on it. Instead follow the pattern used by org.eclipse.jgit.test which is to create a temporary directory in the system temporary folder, and configure the Maven surefire plugin to use the target directory. Change-Id: Iebe5093332343a90f51080614e083aac0d29c26d
* Add tests for DirCacheCheckout and symlinksChristian Halstrick2013-07-101-0/+99
| | | | | | | | | | | | DirCacheCheckout had a bug when the parentdirectory of a worktree was a symlink. DirCacheCheckout was deleting those symlinks under certain conditions. This was fixed in I81735ba0394ef6794e9b2b8bdd8bd7e8b9c6460f without a test because previously it was hard to setup tests containing symlinks. BUG: 412489 Change-Id: I2513166af519d6fc01d1eae3976ad6cff6f98530 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Extend the FS class for Java7Robin Rosenberg2013-05-041-0/+115
The most important difference is that in Java7 we have symbolic links and for most operations in the work tree we want to operate on the link itself rather than the link target, which the old File methods generally do. We also add support for the hidden attribute, which only makes sense on Windows and exists, just since there are claims that Files.exists is faster the File.exists. A new bundle is only activated when run with a Java7 execution environment. It is implemented as a fragment. Tycho currently has no way to conditionally include optional features based on the java version used to run the build, this means with this change the jgit packaging build always needs to be run using java 7. Change-Id: I3d6580d6fa7b22f60d7e54ab236898ed44954ffd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 02:25:03 +0000