git tfs clone/pull does not detect renames to path outside of cloned path

[fschwiet]

I ran into an issue, when using git tfs pull, where the tfs remote only contains a subpath of the TFS repository.

A past checkin to TFS moved a large directory within the target directory to an outside directory. This changeset showed up as a list of Rename changes in our TFS history. TfsHelper.GetChangesets() did not see this
changeset since all the renamed files were outside of the path being cloned/pulled. So the original files were left in the repository.

One solution would be to query all changesets in the repository, but then only keep the changes that impact a file in the subdirectory being cloned.

[spraints]

Interesting find. I'm not sure what the best way to deal with this is. Querying all changesets would work. Would querying all changesets from the team project be good enough? I.e. is your clone a deep path into a project, as opposed to an entire team project?

Also, is the changeset that moved the directory reflected in the git history at all? You may be able to view it directly with "git show tfs/default/C####", using the #### of the changeset that moved the files out of the target directory.

[fschwiet]

I made changes to query all changesets. It will only git commit if the changeset affects the targetted tree.

It is very slow. I have to wait a bit to see if it works :)

[fschwiet]

It didn't work. :) I think there is a problem in the code.

Any thoughts on how best to debug git-tfs? Currently I flip to visual studio and attach to process as its running. This isn't sufficient when the problem occurs before I can attach the debugger.

After running the code, which you might review here: http://github.com/fschwiet/git-tfs/commit/a1e2707a89917e384e658bc70799c967292cc65c it ran for awhile then failed due to network connectivity loss. In the meantime only two changesets were picked up, it was still scanning through changeset history to get to changesets that affect the branch I was looking at.

Anyhow, after it failed, it looks like the problem is there is no HEAD branch. The results of git show-ref look wrong, can you verify this is not as expected?

$ git show-ref
c708dd0b8a05e107206f5ca08aaaf68ca40a617f refs/remotes/tfs/default
849b041c10adf4a03b72aa619657f2a15649989f refs/tags/tfs/default/C36060
c708dd0b8a05e107206f5ca08aaaf68ca40a617f refs/tags/tfs/default/C51191

I would expect to see a master branch and a head. Not sure how my changes could have caused this problem, maybe the network failure prevented them from being created.

thanks

[spraints]

I usually debug git-tfs by running it directly in VS. In the project properties debug panel, if you set the working directory and command line arguments, it should work. I sometimes have problems with git-tfs not being able to find git, which you can fix by setting the full path to git.cmd in [1]

It sounds like you ran into two problems: HEAD not existing and the fetch failing.

HEAD is initialized by clone after the fetch finishes. So if fetch failed after pulling two changesets, then I wouldn't expect HEAD or master to be set up right.

So the real problem is that fetch isn't working right. I wonder if the TFS client lib is expecting the HTTP connection to be open at [2], but if it's closed because of a timeout or other problem. Hopefully debugging will help you figure that out.

[1] http://github.com/spraints/git-tfs/blob/master/GitTfs/Core/GitHelpers.cs#L215

[2] http://github.com/fschwiet/git-tfs/commit/a1e2707a89917e384e658bc70799c967292cc65c#L7R155

[spraints]

I'm closing this because of inactivity.

However, if you're still running into this problem, I've added a 'verify' command (git tfs verify) that will check for differences between TFS and git.

Please reopen this if you're still having a problem.