![]() 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> |
||
---|---|---|
org.eclipse.jgit | ||
org.eclipse.jgit.ant | ||
org.eclipse.jgit.ant.test | ||
org.eclipse.jgit.archive | ||
org.eclipse.jgit.console | ||
org.eclipse.jgit.http.apache | ||
org.eclipse.jgit.http.server | ||
org.eclipse.jgit.http.test | ||
org.eclipse.jgit.java7 | ||
org.eclipse.jgit.java7.test | ||
org.eclipse.jgit.junit | ||
org.eclipse.jgit.junit.http | ||
org.eclipse.jgit.packaging | ||
org.eclipse.jgit.pgm | ||
org.eclipse.jgit.pgm.test | ||
org.eclipse.jgit.test | ||
org.eclipse.jgit.ui | ||
tools | ||
.eclipse_iplog | ||
.gitattributes | ||
.gitignore | ||
LICENSE | ||
README.md | ||
SUBMITTING_PATCHES | ||
pom.xml |
README.md
Java Git
An implementation of the Git version control system in pure Java.
This package is licensed under the EDL (Eclipse Distribution License).
-
org.eclipse.jgit
A pure Java library capable of being run standalone, with no additional support libraries. It provides classes to read and write a Git repository and operate on a working directory.
All portions of jgit are covered by the EDL. Absolutely no GPL, LGPL or EPL contributions are accepted within this package.
-
org.eclipse.jgit.ant
Ant tasks based on JGit.
-
org.eclipse.jgit.http.server
Server for the smart and dumb Git HTTP protocol.
-
org.eclipse.jgit.pgm
Command-line interface Git commands implemented using JGit ("pgm" stands for program).
-
org.eclipse.jgit.test
Unit tests for org.eclipse.jgit and the same licensing rules.
Warnings/Caveats
-
Symbolic links are not supported because java does not support it. Such links could be damaged.
-
Only the timestamp of the index is used by jgit check if the index is dirty.
-
Don't try the library with a JDK other than 1.6 (Java 6) unless you are prepared to investigate problems yourself. JDK 1.5.0_11 and later Java 5 versions may work. Earlier versions do not. JDK 1.4 is not supported. Apple's Java 1.5.0_07 is reported to work acceptably. We have no information about other vendors. Please report your findings if you try.
-
CRLF conversion is performed depending on the core.autocrlf setting, however Git for Windows by default stores that setting during installation in the "system wide" configuration file. If Git is not installed, use the global or repository configuration for the core.autocrlf setting.
-
The system wide configuration file is located relative to where C Git is installed. Make sure Git can be found via the PATH environment variable. When installing Git for Windows check the "Run Git from the Windows Command Prompt" option. There are other options like the jgit.gitprefix system propety or Eclipse settings that can be used for pointing out where C Git is installed. Modifying PATH is the recommended option if C Git is installed.
-
We try to use the same notation of $HOME as C Git does. On Windows this is often not same value as the user.home system property.
Package Features
-
org.eclipse.jgit/
-
Read loose and packed commits, trees, blobs, including deltafied objects.
-
Read objects from shared repositories
-
Write loose commits, trees, blobs.
-
Write blobs from local files or Java InputStreams.
-
Read blobs as Java InputStreams.
-
Copy trees to local directory, or local directory to a tree.
-
Lazily loads objects as necessary.
-
Read and write .git/config files.
-
Create a new repository.
-
Read and write refs, including walking through symrefs.
-
Read, update and write the Git index.
-
Checkout in dirty working directory if trivial.
-
Walk the history from a given set of commits looking for commits introducing changes in files under a specified path.
-
Object transport Fetch via ssh, git, http, Amazon S3 and bundles. Push via ssh, git and Amazon S3. JGit does not yet deltify the pushed packs so they may be a lot larger than C Git packs.
-
-
org.eclipse.jgit.pgm/
- Assorted set of command line utilities. Mostly for ad-hoc testing of jgit log, glog, fetch etc.
Missing Features
There are some missing features:
- gitattributes support
Support
Post question, comments or patches to the jgit-dev@eclipse.org mailing list. You need to be subscribed to post, see here:
https://dev.eclipse.org/mailman/listinfo/jgit-dev
Contributing
See the EGit Contributor Guide:
http://wiki.eclipse.org/EGit/Contributor_Guide
About Git
More information about Git, its repository format, and the canonical C based implementation can be obtained from the Git website: