JGit checkout vs `git checkout` problems

Question

tl;dr JGit's checkout throws exceptions while command line git checkout works fine

I'm currently trying to use JGit to check out certain revisions from an online Git repository, in Java (for work). My current approach is (and I'm very new to Git, coming from a SVN background, so this may be wrong):

• clone the repository to a temporary location on my hard drive
• figure out which revision I want, (I have tried using the SHA-1 hash as well as the name of a branch)
• checkout that revision
• from there, I would be using the checked out files as inputs to a later part of the program.
• checkout a different revision
• use those files as inputs to another part of the program

Essentially, I want to be able to swap the contents of my temp folder with whichever revision. With the command line interface I've been able to do this with git checkout master and git checkout dylanbranch (where dylanbranch is a branch I made on my own clone with an arbitrarily chosen revision), but my Java code attempting to do the same thing fails:

Git git = Git.open(new File("checkout")); //checkout is the folder with .git
git.checkout().setName("master").call(); //succeeds
git.checkout().setName("dylanbranch").call(); //fails

And the exceptions printed to the console:

Exception in thread "main" org.eclipse.jgit.api.errors.JGitInternalException: Checkout conflict with files: 
src/sizzle
test/qunit
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:211)
    at com.avi.scm.git.BranchCheckout.main(BranchCheckout.java:30)
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files: 
src/sizzle
test/qunit
    at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:387)
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:162)
    ... 1 more

I can verify that the files in question are marked as deleted and not staged for commit by using git status though I'm not sure why those changes are there, and they come back any time I switch back to the master branch. Despite that, I can still successfully change the working tree with command line Git.

So my question: Why won't JGit work for this application when command line git will? Any other helpful information is appreciated- educate me :)

Update I've been testing with the jQuery repository, and have noticed a few more problems with JGit: When I am working with the "master" branch, git status temms me that I'm #On branch master and that there is nothing to commit (working directory clean) , but using JGit's status command I see that test/qunit and src/sizzle are marked as Missing . JGit's reset seems to do nothing.

Answer 1

The two directories mentioned in the stack trace are Git submodules ( test/qunit and src/sizzle ) which is most likely the cause of the problem since JGit does not have full submodule support yet.

This may function differently in the 1.1 JGit release due out this month based on this commit .

You can read more about the current state of JGit submodule support here .

Answer 2

I know this doesn't directly answer your question, but I've also had problems with the Java implementations of Git. What worked best for me was to simply ditch the java implementations, and execute command-line calls to git from within the application. It may not be ideal, but it'll do exactly what you want since you'll fully control the command.

Simply call Runtime.getRuntime().exec(...)

Link to Javadoc for Runtime class

Answer 3

I had a similar problem with Checkout. I think that the fact that you can switch branch with unstaged content in Git is actually a tolerance, not a feature. JGit is globally not as tolerant as Git, so you should usually test many cases.

It seems it is not directly your problem (which is related to the submodules), but for more general cases you would want to commit your changes before using checkout to switch to another branch.

Note that the CheckoutCommand works perfectly for me to start a new branch from an old revision (you have to set the name of the branch and the start revision).