Just remove ".setAllPaths(true)" . What your are doing with your code is a checkout which is using a pathspec (see last variant in http://git-scm.com/docs/git-checkout). Something like "git checkout <commit> -- ."
I think the CheckoutCommand should allow to checkout a commit by specifying a RevCommit without
the commit's name since if you already have the RevCommit it's unnecessary overhead to render the
RevCommit's name and reparse it in order to execute the checkout.
I agree that it's odd to require a name if a RevCommit is provided and no new branch is being made.
But I have a more serious problem now. I'm running checkout on a whole series of RevCommits. It chugs along fine for awhile and then fails with "Checkout conflict". I know for sure there are no conflicts since I did exactly the same series of checkouts, in the same sequence, by launching each with a process that runs "git checkout":
So JGit is finding a checkout conflict where Git does not. The so-called conflict is apparently due to line-break differences. The repository configuration has core.autocrlf set to 'input' so I would have expected JGit to ignore line-breaks entirely when it's trying to determine whether or not a checkout is in conflict. As I understand it, the 'input' setting should leave the working files with unix line-breaks regardless of what's in any given commit.
I'm not currently set up to debug JGit. I've been interested for some time in contributing but I never quite seem to get around to going through the all the steps in the set-up procedure. Maybe I can debug just with a clone of the sources? I'll look into that.
In the meantime I'll see if I can construct a small generic repository that replicates the problem.
When you are investigating why E/JGit then you should inspect IndexDiffFilter.include() -> WorkingTreeIterator.isModified() -> WorkingTreeIterator.compareMetaData()
Very roughly the following happens when E/JGit does a "git status":
1 for each distinct path p we find in (workingtree, index, head)
2 if index(p).* differs from head(p).* mark p as dirty and continue loop
3 compare workingtree and index:
4 if index(p).assumeValid mark p as clean and continue loop
5 if index(p).isUpdateNeeded mark p as dirty and continue loop
6 if !index(p).isSmudged and index(p).length!=workingtree(p).length mark p as dirty and continue loop
7 if index(p).mode!=workingtree(p).mode mark p as dirty and continue loop
8 if index(p).lastModified != workingtree(p).lastmodified do content comparison between index(p) and workingtree(p) . report p as dirty/clean accordingly and continue loop
9 if index(p).lastModified == workingtree(p).lastmodified and !index(p).isSmudged mark p as clean and continue loop
10 do content comparison between index(p) and workingtree(p). report p as dirty/clean accordingly
If you only work with E/JGit then this should be fine. E/JGit would checkout ignoring any .gitattribute files. When the process us forces E/JGit to do content checks everything is fine.
Problems arise if you use also native git. E.g. you checkout with native git (e.g. during a initial clone, pull,...). Native git will do content modification before it writes to workingtree. This will even change the length of the file beeing different from the length recorded in the index. If you ask native git about the status everything is ok. Native git knows it has modified the file while writing to workingtree and will do the reverse operation to find out whether a file is dirty or not. But if you ask E/JGit things get problematic. Whenenver E/JGit has to do the content-check then E/JGit will report dirty files because of line 6 or 10.
One could thing: Even if native git checks out wouldn't the algorithm above would allow E/JGit not to have to do a content-check. Native git checks out and E/JGit should detect that the files have not been modified by purely looking at metadata (line 9). But line 6 and smudged entries ruin that.
Maybe we should move line 6 deeper down in the algorithm (behind line 9). This may solve some of the problems. I'll try that
But still: unless JGit learns about .gitattributes there will always be problems in this area.
Problems arise if you use also native git. E.g. you checkout with native git (e.g. during a initial clone, pull,...)
That would explain it then. This specific repository includes a number of oversized commits which seem to be problematic for JGit. So I generally use EGit/JGit for local operations and also for push, while using Git for clone, pull and fetch. I also run 'git status' regularly.
Operationally this seems to work ok in a normal work flow: I can do checkouts with EGit without any issues. But given your description I can see how more exotic uses of checkout, like walking through an arbitrary list of commits and doing a checkout each one in turn, could run into be problems.
regarding your initial question of how to checkout a commit: don't use '.setStartPoint()' when you don't want to create a new branch. This is not described correctly, I agree. But we have tried to stick with the wording on git man-page. Look at http://git-scm.com/docs/git-checkout and look for "start_point" to see when a git checkout needs a "start_point". That's when creating a new branch. Something like "git checkout -b my_new_branch HEAD~2". You want to create a new branch my_new_branch, let him start from HEAD~2 and finally checkout that new branch.
But in your case it's more simple:
If you checkout with JGit instead of native git you could also get around your problems with wrong status as I described before.
ctl-backslash shows the "main" thread sitting in a zip inflater, where it's been for the past 50+ minutes
at java.util.zip.Inflater.inflateBytes(Native Method)
- locked <0x0000000121e45d98> (a java.util.zip.ZStreamRef)
- locked <0x000000016adc8068> (a java.io.BufferedInputStream)
You probably need to increase jgit's cache buffering IO on pack files "core.packedGitLimit"
and if your repository contains large files also increase "core.streamFileThreshold" to some
value larger than the largest file you expect. This may require that you also increase max
Was this repository packed / GCed with jgit ? Since jgit doesn't understand gitattributes yet it has no reliable way to
detect that your big binary files are binary. At the moment jgit uses the following heuristic check to detect binary files:
if a file contains a null byte in the first 8kB jgit assumes it's a binary file. If one of your big binaries happens to not
match this, jgit will try to compute deltas which may lead to problems. You could try what Shawn proposed at the end
of the above mentioned mail on the list.