"git-tf: Missing tree" on checkin

Mar 7, 2013 at 2:19 PM
I am getting a "git-tf: Missing tree <sha1>" message when performing a git tf checkin --deep or git tf checkin.
I performed some rather extensive git filter-branch operations along with some grafts to prep the repository for interaction with TFS. Before that I had the problem of different case of the same folder.

The git repository seems to work fine, I can commit, rebase, switch branches, push and pull...
git fsck --full returns nothing.

Still, I recognize the possibility that I might have corrupted the repository with my massive changes. The question is: How to find the actual problem?
Even when specifying --verbose I don't get additional info from git tf, so I don't have a starting point, because I don't know what git tf is trying to do...

Any ideas how to go forward from here?
Mar 7, 2013 at 2:47 PM
Hi dhilgarth,

I'm sorry to hear that you're experiencing the issue with Git-TF. Do you have any logs (%LOCALAPPDATA%\Microsoft\Team Foundation\4.0\Logs\git-tf-*.log) corresponding for the run with that error? Could you please provide them?

Meantime, could you please answer few questions?
  1. Do I understand well that running the git tf checkin command you wished to execute a shallow operation? Is it possible that deep operations are set up in the config file as default? So, you might wish to try git tf checkin --shallow to be sure.
  2. Could you look in the git-tf file in your .git folder, does it contain the <sha1> mentioned in the message? If it does contain it, could you please verify that a commit with that <sha1> exists iny our Git repository?
Alex Rukhlin
Mar 7, 2013 at 4:19 PM
Edited Mar 7, 2013 at 4:21 PM
Alex, thanks for your prompt answer.

I also tried git tf checkin --shallow with the same result. But I don't think that deep checkins are set as default:
    depth = 1
    file-format-version = 1
    tag = true
There is indeed a log file and it contains a stack trace:
2013-03-07 15:31:08,743 ERROR [main] (git-tf) Error executing task CheckinHeadCommitTask
 org.eclipse.jgit.errors.MissingObjectException: Missing tree 72383dc3a754e96a6d2271af91825b96150a40db
    at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:126)
    at org.eclipse.jgit.treewalk.CanonicalTreeParser.reset(CanonicalTreeParser.java:201)
    at org.eclipse.jgit.treewalk.CanonicalTreeParser.createSubtreeIterator0(CanonicalTreeParser.java:235)
    at org.eclipse.jgit.treewalk.CanonicalTreeParser.createSubtreeIterator(CanonicalTreeParser.java:213)
    at org.eclipse.jgit.treewalk.CanonicalTreeParser.createSubtreeIterator(CanonicalTreeParser.java:60)
    at org.eclipse.jgit.treewalk.TreeWalk.enterSubtree(TreeWalk.java:908)
    at com.microsoft.gittf.core.tasks.pendDiff.PendDifferenceTask.validateCaseSensitivityRequirements(PendDifferenceTask.java:351)
    at com.microsoft.gittf.core.tasks.pendDiff.PendDifferenceTask.validateTree(PendDifferenceTask.java:305)
    at com.microsoft.gittf.core.tasks.pendDiff.PendDifferenceTask.validate(PendDifferenceTask.java:287)
    at com.microsoft.gittf.core.tasks.CheckinHeadCommitTask.run(CheckinHeadCommitTask.java:411)
    at com.microsoft.gittf.core.tasks.framework.TaskExecutor.execute(TaskExecutor.java:145)
    at com.microsoft.gittf.client.clc.commands.CheckinCommand.run(CheckinCommand.java:215)
    at com.microsoft.gittf.client.clc.Main.main(Main.java:328)
As the message says, the object with that sha1 is a tree, not a commit. And it does exist:
C:\Path> git show 72383dc3a754e96a6d2271af91825b96150a40db
tree 72383dc3a754e96a6d2271af91825b96150a40db

But it doesn't occur in the file git-tf. I would actually find it strange if a tree-hash would appear there.

Mar 7, 2013 at 6:51 PM
Hi Daniel,

As I can see in the exception stack, JGit cannot open the file ...\.git\objects\72\383dc3a754e96a6d2271af91825b96150a40db . Could it happen that this file is damaged somehow? What would the git ls-tree -r -t -l 72383dc3a754e96a6d2271af91825b96150a40db command show?

Also, is it possible to provide us with your Git repository? We could try and run JGit in debug mode... Please contact me @ my personal e-mail (arukhlin@microsoft.com) if we could discuss this.

Mar 8, 2013 at 7:24 AM
Hi Alex,

that file doesn't exist. I guess it went into some of the pack files, because I performed an aggressive gc.

Providing you with the repository is not possible, I am sorry.

I was able to fix the problem in the meantime. It is pretty strange.

What I did the last days was the following
  1. I performed several git filter-branch --index-filter commands that fixed the casing of my files and folders. I performed these operations in repository A.
  2. After that I force pushed my branches to the origin.
  3. I now cloned the origin into a separate local repository (B) that I then connected to TFS using tf configure.
  4. After cloning B I noticed that part of my history existed twice. One history was connected to my branches, the other to my tags.
  5. It turned out that I had forgotten to push the updated tags in step 2.
  6. I now did that via git push --tags on A and fetched the updated tags via git fetch --tags on B in the local repository.
  7. After that git fsck on B showed a dangling commit I couldn't get rid of and git tf showed the above mentioned error.
Now, what actually fixed that error was rather brutal:
  1. I deleted origin and created a new bare repository, which I filled then from A via git push --all and git push --tags.
  2. I deleted B and created a fresh clone.
But I still don't really understand why git tf had a problem with the first clone.

Mar 8, 2013 at 3:30 PM

Hi Daniel,

I’m glad to hear the Git-TF is working for you now.

As for the issue you experienced, it could be produced either by a bug in the Git itself (which we cannot affect unfortunately), or by a bug or lack of functionality in the JGit package we use to execute git-operations. As it is an open source product we ship with Git-TF, in principle, we could submit either a claim or a patch (if we could produce it :-) ) to them. We’ll add this task to our back log (thanks for finding!) and will work on it according to priorities.



Mar 19, 2013 at 11:13 AM
A last info from me:
git ls-tree -r -t -l 72383dc3a754e96a6d2271af91825b96150a40db outputs this:
100644 blob 41f0bb94dd9bae27aa188267eeb7ff7e64d749f3 5242715    Release.1.1.0.zip
100644 blob 3687046974b045959bd461f67fad428460b6b35c 4933823    Release.1.1.1.zip