"Unable to locate a remote for" error

[dan.li...@gmail.com]

Hi,

I've been using git tfs for ages and am suddenly getting the following error when trying to fetch or use rcheckin.

Unable to locate a remote for <http://xxx:8080/tfs/xxx>$/Url with spaces/ProjectName 

You may be able to resolve this problem.

- Try using `git tfs bootstrap` to auto-init TFS remotes.

- Try setting a legacy-url for an existing remote.

I'm using version 0.15.0 from Chocolatey.

I have the same repository on two different computers and have the same error on both. Running bootstrap doesn't help and even cloning again doesn't help. I can clone the repository but git tfs fetch produces the error above. If I create a new tfs-remote then I can fetch once but the second time I try to fetch throws the same exception.

I ran git tfs --debug fetch and got this:

git command: Starting process: git config --list

git command time: [00:00:00.0935970] config --list

Fetching from TFS remote default

git command: Starting process: git log --no-color --pretty=medium refs/remotes/tfs/default

git command time: [00:00:00.0155995] log --no-color --pretty=medium refs/remotes/tfs/default

Sep.Git.Tfs.Core.GitTfsException: Unable to locate a remote for <http://xxx:8080/tfs/xxx>$/Url with spaces/ProjectName  ---> Sep.Git.Tfs.Core.GitTfsException: Unable to locate a remote for <http://xxx:8080/tfs/xxx>$/Url with spaces/ProjectName 

   at Sep.Git.Tfs.Core.GitRepository.ReadTfsRemote(String tfsUrl, String tfsRepositoryPath, Boolean includeStubRemotes) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 78

   at Sep.Git.Tfs.Core.GitRepository.TryParseChangesetInfo(String gitTfsMetaInfo, String commit, Boolean includeStubRemotes) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 287

   at Sep.Git.Tfs.Core.GitRepository.FindTfsCommits(TextReader stdout, ICollection`1 tfsCommits, Boolean includeStubRemotes) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 271

   at Sep.Git.Tfs.Core.GitRepository.<>c__DisplayClass13.<GetParentTfsCommits>b__11(TextReader stdout) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 249

   at Sep.Git.Tfs.Core.GitHelpers.<>c__DisplayClass8.<CommandOutputPipe>b__7() in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitHelpers.cs:line 58

   at Sep.Git.Tfs.Core.GitHelpers.Time(String[] command, Action action) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitHelpers.cs:line 182

   at Sep.Git.Tfs.Core.GitHelpers.CommandOutputPipe(Action`1 handleOutput, String[] command) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitHelpers.cs:line 54

   at Sep.Git.Tfs.Core.GitRepository.GetParentTfsCommits(String head, Boolean includeStubRemotes) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 249

   at Sep.Git.Tfs.Core.GitRepository.GetLastParentTfsCommits(String head, Boolean includeStubRemotes) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 237

   at Sep.Git.Tfs.Core.GitRepository.GetLastParentTfsCommits(String head) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 232

   at Sep.Git.Tfs.Core.GitTfsRemote.InitHistory() in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitTfsRemote.cs:line 82

   at Sep.Git.Tfs.Core.GitTfsRemote.get_MaxChangesetId() in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitTfsRemote.cs:line 70

   at Sep.Git.Tfs.Core.GitRepository.MoveTfsRefForwardIfNeeded(IGitTfsRemote remote) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Core\GitRepository.cs:line 109

   at Sep.Git.Tfs.Commands.Fetch.DoFetch(IGitTfsRemote remote) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Commands\Fetch.cs:line 90

   at Sep.Git.Tfs.Commands.Fetch.Run(String[] args) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Commands\Fetch.cs:line 78

   at Sep.Git.Tfs.Commands.Fetch.Run() in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Commands\Fetch.cs:line 56

   --- End of inner exception stack trace ---

   at Sep.Git.Tfs.Util.GitTfsCommandRunner.Run(GitTfsCommand command, IList`1 args) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Util\GitTfsCommandRunner.cs:line 32

   at Sep.Git.Tfs.GitTfs.Main(GitTfsCommand command, IList`1 unparsedArgs) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\GitTfs.cs:line 56

   at Sep.Git.Tfs.GitTfs.Run(IList`1 args) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\GitTfs.cs:line 40

   at Sep.Git.Tfs.Program.Main(String[] args) in c:\Users\matt\dev\github\git-tfs-release\GitTfs\Program.cs:line 24

Unable to locate a remote for <http://xxx:8080/tfs/xxx>$/Url with spaces/ProjectName 

You may be able to resolve this problem.

- Try using `git tfs bootstrap` to auto-init TFS remotes.

- Try setting a legacy-url for an existing remote.

If no-one knows why this is happening, I'll see if I can produce a pull request for it. 

Cheers,

Daniel

[Matt Burke]

I would guess one of a couple of things happened.

First, did the tfs-remote configs disappear? In your repo, you should
be able to `git config -l --local` and see a few entries that start
with 'tfs-remote.default.' If they're not there, try doing `git tfs
bootstrap`.

If they are there, maybe there's a case difference between the URL or
project in the changeset message and the information in the config
vars. The repo path [1] and url [2] are both compared
case-sensitively.

[1] https://github.com/git-tfs/git-tfs/blob/master/GitTfs/Core/GitRepository.cs#L71-73
[2] https://github.com/git-tfs/git-tfs/blob/master/GitTfs.VsCommon/TfsHelper.Common.cs#L475-478

Is one of those things the problem?

--
Matt

> --
> You received this message because you are subscribed to the Google Groups
> "git-tfs-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/git-tfs-dev/-/BQt2O7CJrOsJ.
> To post to this group, send email to git-t...@googlegroups.com.
> To unsubscribe from this group, send email to
> git-tfs-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/git-tfs-dev?hl=en.

[dan.li...@gmail.com]

Hi Matt,

Thanks for the reply. I have all the config options (tfs-remote.default.url, tfs-remote.default.repository and tfs-remote.default.fetch). 

Looking more closely, I am noticing that the casing in the url is not correct in the error message. In the .git/config file and when I do git config -l, the url looks like this: http://somehost:8080/tfs/Active but in the error message it looks like this: http://somehost:8080/tfs/active (with a lower a in active). And when I call git tfs bootstrap, it has an uppercase A for the other branch in the repo but not the default branch. So that could be the problem.

How do I fix that? It looks right in the config file.

Thanks,

Daniel

[dan.li...@gmail.com]

Noticing something else as well. I have two TFS branches in my repo. If I do a git fetch then the error message contains the url for the other branch. If I do a git bootstrap and it adds the other branch as a new TFS-remote, then the error message specifies the correct branch but with a lower-case a in Active. Don't know if that helps.

//Daniel

[Matt Burke]

I think we can make the url and repo path comparisons case
insensitive. If it solves your problem, could you make a pull request
for it?

Thanks!
Matt

> --
> You received this message because you are subscribed to the Google Groups
> "git-tfs-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/git-tfs-dev/-/L38s7Yhp7GQJ.

[dan.li...@gmail.com]

I'll give it a shot. I won't mess anything else up by making it case insensitive?

//Daniel

[Matt Burke]

In theory, URLS and TFS paths are case sensitive. In practice, TFS
paths aren't (from what I've seen), and TFS servers are usually hosted
on IIS on Windows, so I've never seen them be case sensitive, either.
I think it's all good.

--
Matt

> --
> You received this message because you are subscribed to the Google Groups
> "git-tfs-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/git-tfs-dev/-/CcjNqgSd-j0J.

[dan.li...@gmail.com]

Hi Matt,

Any tips for integration testing the fetch command? A unit test for the TfsHelper class is no problem and I can test it against my problem tfs repo by running the git-tfs exe. But it isn't totally clear to me how to do a good integration test for this.

By the way, you really need to update your contributing guidelines. The wiki seems to be locked so I'll submit that as a separate pull request.

//Daniel

[dan.li...@gmail.com]

Ok, I'm also wondering how do you unit test TfsHelperBase? Or any of the VS-specific classes?  I think I'll extract the MatchesUrl method to another class to be able to test it.

[dan.li...@gmail.com]

Made a start on this and changed it to be case insensitive which solves my problem. The branch is here: https://github.com/daniellee/git-tfs/tree/caseinsensitive

I'd like to get a few more tests around it before submitting it but got a bit stuck there. I'm thinking either something in the style of the CloneTests or a focused integration test for the GitRepository class. What do you think?

//Daniel

[Matt Burke]

> Made a start on this and changed it to be case insensitive which solves my
> problem. The branch is here:
> https://github.com/daniellee/git-tfs/tree/caseinsensitive

Cool. I like the direction.

> I'd like to get a few more tests around it before submitting it but got a
> bit stuck there. I'm thinking either something in the style of the
> CloneTests or a focused integration test for the GitRepository class. What
> do you think?

Unfortunately, it's pretty painful to test things in GitRepository
right now. I've started some refactorings that will eventually help
(https://github.com/spraints/git-tfs/tree/refactor-to-functional-core),
but it's not ready yet.

Integration tests on git-tfs-fetch would be good.

> Ok, I'm also wondering how do you unit test TfsHelperBase? Or any of the
> VS-specific classes? I think I'll extract the MatchesUrl method to another
> class to be able to test it.

I wouldn't make tests for TfsHelperBase. It's too close to the TFS
client libs, and I would like the unit tests to be able to build and
run without any TFS client libs on the system. (Among other things,
this makes CI a more sane thing to tackle.) If you want tests for the
case-insensitivity, either do an integration test or pull out the
comparison so that it's in the GitTfs project, and not in the
GitTfs.Vs* projects (ie. not in TfsHelperBase).

--
Matt

[dan.li...@gmail.com]

Hi Matt,

I didn't get much done on this during December but now I am just about finished but got stuck on a problem with the fake helper class for TFS. I have written some integration tests for fetch/pull but think I have found an off-by-one bug in https://github.com/git-tfs/git-tfs/blob/master/GitTfs.VsFake/TfsHelper.VsFake.cs#L57-60 when combined with this method call: https://github.com/git-tfs/git-tfs/blob/master/GitTfs/Core/GitTfsRemote.cs#L209 

The logic here is that when fetching changesets from fake TFS that the first changeset is skipped. Is this just a bug or is this a replication of the behavior of TFS? Is the first changeset skipped when cloning a repository? The CloneTests seem to say that this is expected behavior (see here https://github.com/git-tfs/git-tfs/blob/master/GitTfsTest/Integration/CloneTests.cs#L51-52 ). On the other hand the test for cloning an empty repo is broken (https://github.com/git-tfs/git-tfs/blob/master/GitTfsTest/Integration/CloneTests.cs#L29-44) as the first changeset is skipped and you cannot clone a repo without commits it would seem.

I tried to do a test where first I create a git repo with two commits by using git tfs clone and then I add two more commits and do a pull. The end result is that instead of 4 commits I have only 2. To fix this, I was thinking that either I make a change to TfsHelper.VsFake so that the comparison to startVersion is not off-by-one and then fix all the CloneTests or that I change the comparison to only skip the first changeset instead of every second changeset?

Any advice or background you can give me?

Thanks,

Daniel

[Matt Burke]

I agree that it looks like there's an off-by-one. I didn't double-check the behavior with a TFS server when I wrote the VsFake code. VsFake [1] should be changed from `>` to `>=`, and the tests will need to be updated, too. Maybe it'll fix the empty clone test. I remember being confused about why that didn't work. This is probably why.

[1] https://github.com/git-tfs/git-tfs/blob/master/GitTfs.VsFake/TfsHelper.VsFake.cs#L57-60

Daniel

--
You received this message because you are subscribed to the Google Groups "git-tfs-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/git-tfs-dev/-/xh_sxkH-2H8J.

[Matt Burke]

I changed it to >= in https://github.com/git-tfs/git-tfs/commit/3fc13957dddbc38161d6050285e85ce68498a19a and CloneEmptyProject works now. Thanks for finding this!

[dan.li...@gmail.com]

Thanks, that was the change I'd done locally as well. I'll get my pull request in tomorrow. Thanks for taking the time to answer all my questions.