git-tf checkin Exception in thread “main” java.lan

Question

I am trying to take an existing git repository and check it in to TFS Preview using git-tf, and I am getting an error when I try to do the check in. Here is what I have done so far.

1. git clone -b https://github.com/.git to clone the branch that I want to check in. I want to check in a branch that isn't named master into TFS.

2. cd into local path of code.

3. git tf configure https://.tfspreview.com/DefaultCollection $/ Then, I configured git tf to configure the TFS connection.

4. git tf checkin Then, I got the following error:

Checking in to $/: 0% git-tf: no HEAD ref

1. So I then created a master branch since I didn't have one by doing the following: git branch -b master

2. Switched back to the branch I checked out: git checkout .

3. Tried the check in again: git tf checkin.

4. That got me past the first error. However, I got the following error, and I am not sure what to do about this.

Does anyone have any ideas on how to get past the error below from running git tf checkin?

Thanks!

Connecting to TFS...
Checking in to $/Sandbox/HammerheadGitTest/sCRM: 
Exception in thread "main" java.lang.StackOverflowError
    at java.io.RandomAccessFile.seek(Native Method)
    at org.eclipse.jgit.storage.file.PackFile.read(PackFile.java:614)
    at org.eclipse.jgit.storage.file.WindowCache.load(WindowCache.java:314)
    at org.eclipse.jgit.storage.file.WindowCache.getOrLoad(WindowCache.java:393)
    at org.eclipse.jgit.storage.file.WindowCache.get(WindowCache.java:204)
    at org.eclipse.jgit.storage.file.WindowCursor.pin(WindowCursor.java:334)
    at org.eclipse.jgit.storage.file.WindowCursor.copy(WindowCursor.java:203)
    at org.eclipse.jgit.storage.file.PackFile.readFully(PackFile.java:526)
    at org.eclipse.jgit.storage.file.PackFile.load(PackFile.java:684)
    at org.eclipse.jgit.storage.file.PackFile.get(PackFile.java:227)
    at org.eclipse.jgit.storage.file.ObjectDirectory.openObject1(ObjectDirectory.java:439)
    at org.eclipse.jgit.storage.file.FileObjectDatabase.openObjectImpl1(FileObjectDatabase.java:172)
    at org.eclipse.jgit.storage.file.FileObjectDatabase.openObject(FileObjectDatabase.java:157)
    at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:122)
    at org.eclipse.jgit.revwalk.RevWalk.getCachedBytes(RevWalk.java:856)
    at org.eclipse.jgit.revwalk.RevCommit.parseHeaders(RevCommit.java:136)
    at org.eclipse.jgit.revwalk.RevWalk.parseHeaders(RevWalk.java:965)
    at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:814)
    at org.eclipse.jgit.revwalk.RevWalk.parseCommit(RevWalk.java:725)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:260)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)
    at com.microsoft.gittf.core.util.CommitWalker.detectAutoSquashedPath(CommitWalker.java:286)

The last two lines continues over and over again for a long time.

Answer 1

I got a response on codeplex.com with the work around to this issue. Here is the answer I got:

Hello,

You are seeing this problem because you are trying to check in a huge commit tree with probably more than 2000 - 3000 commits deep. Our code has some recursive logic to identify the commits to be checked in. This logic because it is recursive in nature pushes the JVM call stack size to above the 1800 mark which is around the default limit that the JVM works with, above that there the JVM will throw a StackOverFlowException which you are seeing. This is a JVM limitation, fortunately there is a workaround to extend the stack size using a parameter to get past this error.

You will need to update the git-tf.cmd (git-tf if not running in windows) in your git-tf deployment directory and append –Xss3m to the call to “java.exe”.

We have a user story to make this scenario better in the future.

Thanks, Youhana

Here is a link to the answer: http://gittf.codeplex.com/workitem/43