Unable to clone repository using git-tfs 0.17

[vladiliescu]

As the title says, I've upgraded to v.017 today and clone doesn't seem to work anymore. Running git tfs clone gives me the following output

e:\projects>git tfs clone https://<tfs url>/tfs/DefaultCollection $/<some project>
Initialized empty Git repository in e:/projects/<some project>/.git/
warning: you are going to clone the whole repository or too high in the repository path !
   => If you want to manage branches with git-tfs, clone one of this branch instead :
 - $/<some other totally unrelated project 1>\n - $/<some other totally unrelated project 2>\n - $/<some other totally unrelated project 3>
Object reference not set to an instance of an object.

Rolling back to v0.16.1 fixed the issue. Also, I'm running git v1.8.1.msysgit.1.

[pmiossec]

Can you try to give us the debug trace using the option -d?

And which version of TFS do you use?
I suppose that you are using TFS2010 (or 2012) and that you're projects was migrated from a 2008 version, isn'it? Bacause I know that there is surely problems with this case but we don't have environment like that.

If you could get the sources and debug to give us better informations, it will be perfect...

[vladiliescu]

We're using TFS 2012 - v11.0.51106.1. The particular collection I'm trying to work with (DefaultCollection) has been created using a RC version of TFS 2012, and upgraded several times. We also have a different collection on the same server that has been migrated from TFS 2010, if it matters.

The debug trace output is below, hope it helps.

e:\projects>git tfs clone -d https://<server>/tfs/DefaultCollection "$/<project>"
git-tfs version 0.17.0.0 (TFS client library 11.0.0.0 (MS)) (32-bit)
git command: Starting process: git init
Initialized empty Git repository in e:/projects/<project>/.git/
git command time: [00:00:00.0240000] init
warning: you are going to clone the whole repository or too high in the repository path !
   => If you want to manage branches with git-tfs, clone one of this branch instead :
 - $/<some other project branch 1>\n - $/<some other project branch 1>\n - $/<some other project branch 1>
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Sep.Git.Tfs.Commands.Clone.VerifyTfsPathToClone(String tfsRepositoryPath)
   at Sep.Git.Tfs.Commands.Clone.Run(String tfsUrl, String tfsRepositoryPath, String gitRepositoryPath)
   at Sep.Git.Tfs.Commands.Clone.Run(String tfsUrl, String tfsRepositoryPath)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Sep.Git.Tfs.Util.GitTfsCommandRunner.Run(GitTfsCommand command, IList`1 args)
   at Sep.Git.Tfs.GitTfs.Main(GitTfsCommand command, IList`1 unparsedArgs)
   at Sep.Git.Tfs.GitTfs.Run(IList`1 args)
   at Sep.Git.Tfs.Program.MainCore(String[] args)
   at Sep.Git.Tfs.Program.Main(String[] args)
Object reference not set to an instance of an object.

[pmiossec]

Ok. I have reproduce the problem. And find the bug (a return missing).
I will do a pull request soon.
Thanks for finding and reporting the issue!

[vladiliescu]

And thank you for being so prompt in addressing this!

[pmiossec]

If you could test this version to confirm the correction, it will be very kind :
pmiossec@d7347c8

[vladiliescu]

Looks like I'm unable to build the solution - I don't have the necessary assembly references for the GitTfs.Vs2010 and GitTfs.Vs2008 projects, so I can't test this.

[sc68cal]

Go into the build configuration and disable the 2008 and 2010 builds.

[spraints]

Looks like I'm unable to build the solution - I don't have the necessary assembly references for the GitTfs.Vs2010 and GitTfs.Vs2008 projects, so I can't test this.

Go into the build configuration and disable the 2008 and 2010 builds.

Yeah, do that. As long as one of the GitTfs.Vs* projects builds, you can run git-tfs, even though VS will tell you that you can't. The project is set up so that GitTfs can have just one distribution, and it figures out at runtime which version of TFS it should use. (The alternative is shipping several versions of the product, one for each supported TFS.) The thing you ran into comes up pretty frequently, and I'd like to have a better way to document it, so that anyone who tries to start coding on GitTfs doesn't think they've hit a wall, when they really haven't.

[spraints]

@vladiliescu - 0.17.1 is on git-tfs.com. Can you try it and see if clone is fixed for you?

[vladiliescu]

@spraints, @sc68cal I had tried unloading the 2008/2010 projects from the build, and running git tfs with only the Vs11 reference, but it complained that it couldn't find the assemblies. I also tried replacing them with the ones from v0.17 but that didn't work either, so that's when I gave up.

Anyways, I've tried running v0.17.1 and it still complains about being too high in the repository, but then it goes on and retrieves the changesets.

warning: you are going to clone the whole repository or too high in the repository path !
   => If you want to manage branches with git-tfs, clone one of this branch instead :
 - $/<other project branch 1>\n - $/<other project branch 2>\n - $/<other project branch 3>

[pmiossec]

It's normal that it complains because your are cloning the whole repository which is not what git-tfs expect since there is a branch support in git-tfs. This warning is here to prevent the fact that someone clone the whole repository, then want to work whith branches and will be stuck. So we ask TFS for branches and display it to the user!

That's because, since TFS 2010, a repository is supposed to be architectured like that (but TFS constrains not enough so it's difficult to have a unique pattern across all repositories!) :
$/Project1/trunk
$/Project1/branch1
$/Project1/branch2
$/Project1/branch3
$/Project2/trunk
$/Project2/branch1
$/Project2/branch2
...

And if you follow this pattern, git-tfs tell you that probably it's a better idea to clone one of the $/Project1/trunk or $/Project1/branch2 or ... than clone the whole repository $/Project1 !

But the most important is that it still permit to clone the whole repository (for project not following this pattern) and do it without crash ;)

[vladiliescu]

Ah, I see - the project does indeed have one branch and I was trying to clone the whole repository.

However, the branches suggested by git-tfs have nothing to do with the project I'm working on (they even belong to two other separate projects), so I ignored the warning since it didn't make any sense to me. Are you saying that this is another bug?

[pmiossec]

perhaps :(

However, the branches suggested by git-tfs have nothing to do with the project I'm working on (they even belong to two other separate projects), so I ignored the warning since it didn't make any sense to me.
That's because we ask to TFS all the branches of the repository. It's perhaps too much but we have no way to do it better...

Except if we failed somewhere, we ask TFS to give us the list of the branches and display just the ones that have no parents. That's the way we use to return only the trunks. In my example, $/Project1/trunk and $/Project2/trunk because the others have one of this branch like parent or another branch...

I'm interested if you say that you've got a branch that you think is a "trunk" (not a branched one, so without parent) and that was not displayed in the list of the branches.

[vladiliescu]

Created issue #335 with more details about my scenarios.